The Rubygame Book Part 6

From Kibabase

In this part of the tutorial, you'll be learning how to do test driven development in addition to implementing what we have planned. Unit tests will be an integral part of the tutorial. The actual application code itself will no longer be something to copy. Rather, it is now a reference and example for readers.

Intro to Unit testing

I have forgotten to write unit tests for the dependencity library. However, I will write unit tests for the rest of the project. So it is neccesary for you to be acquinted with test driven development or you will be lost in further part of this tutorial.

So what is test driven development, actually? Well, it is a process in which you write unit tests first, test, and then write code until it passed all unit tests. What you do is write unit tests to test expected outcomes of the smallest unit of code as much as possible.

If done properly, you will gains many benefit today and into the future. They can be a second set of documentation that is automatically maintained as you make changes to the codebase because it will fails your tests and you have to go back and fix it. It makes your code modular because you're forced to make small unit of codes testable. It increases your audacity since it help checks for regression in the codebase.

However, unit tests likely won't test for everything. For that, you will need to run the program and try to find bugs. Unit testing is just another line of defenses in preventing bugs in your toolkits, abiet a very useful line of defense.

A Master Test Program

We need to create a test program that can run parts of the test or all the test, automatically. It will also used dependencity to not only load unit tests but also files that we're going to test.

Before we can write our master test program, create the test/events directory.

Now, we can move on to creating the test program, in the test directory also.

file: test/test.rb

   require "config/environment.rb"
   @loader = Dependencity.new()
   def all
     @loader.add_dir("test/events") #We'll add more directories as we starts to write new codes in new directories such as app/view, app/controller, etc.
     @loader.process_directories()
   end
   def load name
     @loader.add_dir("test/#{name}")
     @loader.process_Directories()
   end

Rakefile

Then we create a Rakefile for rake tasks. Rake is a simply ruby program from which we can use it to not only builds but do other miscellenous tasks as well. We're going to make our first rake task to be about testing.

 file: Rakefile at directory top level

  task :test ,[:load_dir] do |t,args|
    require "rubygems"
    require "rubygame"
    require "test/unit"
    require "test/test.rb"
    args.with_defaults(:load_dir => "all")
    if args.load_dir == "all"
      all()
    else
      load(args.load_dir)
    end
  end

Run it from the commandline:

 rake test

It will do nothing since there are no tests to be done.

Your First Unit Test

 file: test/events/test_mode_manager.rb

  class TestModeManager < Test::Unit::TestCase
    def setup
      @manager = ModesManager.new()
    end
    def test_initialize
      assert @manager.instance_variable_get(:@modes).class == Array
      assert @manager.instance_variable_get(:@modes).size() == 0
    end
  end

With this unit test, we should get an error because mode manager doesn't exist yet.

Writing the ModesManager

The next step in the test driven development is to make a skeleton class for ModesManager.

 file: lib/events/modes_manager.rb

  class ModesManager
    def initialize
    end
  end

If you run the test again, you'll get an error about nonexistent variables. No worry, we'll just need to populate it.

 file: lib/events/mode_manager.rb

  class ModesManager
    def initialize
      @modes = []
    end
  end

Run the unit test again, and you finish your first unit test.

Conclusion

Now you're ready to tackle the world through the use of unit tests. You will be writing your own code using the unit tests I developed for the rest of this book. At the end of each parts, there will be my work to compare against your. Effort to comparse and contrast my work against your is a good learning experience, if only to see how other programmers solve the problem. You could use their approach in your future endeavor to solve similiar problems.

In the next part of the tutorial, we will once again continue the development of your event system by extending Rubygame's. Turn to part 7.