First of all, the tests are very, very self descriptive, with their names being simple strings and not method_names (like in Test::Unit) they tell you everything. I also found out that this way of specifying tests encourages me to write more shorter tests instead of few longer ones.
Secondly, you can see that the standard assertions are well thought, having nice error messages -- no more "hmm, expected, actual or actual, expected in assert_equal?"! user.name.should == "test" to the rescue. What do we expect here? Of course "test".
Also, the nice format of output give you brief but meaningful info about the tests: they are all well pointed out, the failing tests are marked red (or purple, if it's an ERROR), pending tests are marked orange. You can easily output as html to a nice, green page :)
Testing Merb is well thought -- they encourage you to write separate tests for controllers, models, views, helpers, routes etc. and it can be done easily. You can see, that a lot of work was done here to simplify the process and split the tests to small, independent groups (few mocks and stubs are needed to achieve this). For example, you don't test routing in your controller tests, they don't even know what router is, you just dispatch the request to some action of a controller, give it some params and there you go.
P.S
Disadvantage: lack of materials on Merb. After some googling I finally found how to mock session in controller test:
@controller = dispatch_to(MyController, :index) do |controller|
controller.stub!(:session).and_return({:user_id = 3}) # session hash
controller.stub!(:render) # don't render this action
end
0 comment(s):
Post a Comment