Here is my work for Exercise 47.
My code is: on gitHub under the ex47 directory.
1. Go read more about Ruby’s Test::Unit , and also read about alternatives.
Test::Unit is a unit testing framework for Ruby. The idea behind unit testing, is to write test methods that make certain assertions about your code, against a test fixture. A test fixture is fixed state of the software that is used as a baseline for making the tests. An assertion is like making a statement about an expected outcome. “I expect x to be y.”
The assert_equal method tests if the expected result is equal to the actual result. The syntax is assert_equal(expected, result, failure_message = nil). This method tests if expected is equal to result. In our example, we actually have the order switched, but this does not affect the outcome as the method is testing if the two are equal. The default failure_message is nil but we can give it a specific failure message.)
In this example, we create rooms in our test functions. We then use assertions to test the result of the code against our fixtures. On line number 10, we are testing gold.name with our fixed string of “GoldRoom”. On line number 11, we are testing gold.paths to an empty hash. If both assertions are true, the test will pass.
I wanted to see the test fail so I typed “Gold Room” instead of “GoldRoom” on line 10. The result of the test says ” <“GoldRoom”> expected but was <“Gold Room”>”. This was confusing, as the expectation should be “Gold Room”, and the actual should be the returned value of gold.name ? Seems the order of expected and result are reversed.
2. Write a new test case in tests/test_ex47.rb that creates a miniature version of your game from Exercise 45. This is one function that is similar to the current functions, but using your game’s room names and abbreviated descriptions. Remember to use Room.add_paths to create the map, and use assertions to confirm everything works as expected.
I wrote a test_game function that creates all the rooms I made in Exercise 45. I tested all the possible paths the player can play through. I really wished I had a piece of paper to look at the state model!
First I had to think of all the different paths the player could take. The possibilities from start to finish are as below:
basement -> dress -> dress
basement -> dress -> lose
basement -> dress -> necklace -> lose
basement -> dress -> necklace -> zombie -> lose
basement -> dress -> necklace -> zombie -> merman -> lose
basement -> dress -> necklace -> zombie -> merman -> finish
Once we have tested a path, we do not need to test it again. For example, once we have tested that basement -> dress -> necklace -> zombie works, we don’t need to repeat that when we want to test the zombie path. We see that we can simplify the test to the following paths: (This simplifying process was fun!)
basement -> dress -> dress -> lose
dress -> necklace -> lose
necklace -> zombie -> lose
zombie -> merman -> lose
merman -> finish
And, the test passes with five assertions. Success!
In this exercise, we used Test::Unit, a testing framework for Ruby, to test a simple class Room. The class Room has 3 methods, initialize(name, direction), go(direction), and add_paths(path). We created test functions in our test file to test these class methods. Testing is done using assertion. Assertion is when you make a statement about an expected outcome. We put assertions into our test methods. The assert_equals(expected, actual, failure_message=nil) function is used to test our class methods. An optional failure message can be added. If the expected result and the actual result are not equal, the assertion will fail and we will get a default failure message (or our optional failure message). If an assertion fails, the test fails.
Testing is important so that we can check if we have broken anything in our project when we add new code. We should automate testing not only because testing is repetitive, but because it helps us to better understand what is going on in our code.