If that test fails, you have no idea what the actual_result was, since you're only shown what it wasn't.
assertEquals( x, y ) will tell you "Foo" != "Bar", your test will simply say, "failed: Bar". Why did it fail? Being told why it failed usually saves me a minute or two, so I can squeeze more productive work into the time I have available.
People behind nose and py.test are clever cookies but unittest (which ZopeTestCase and Django TestClient is based on) is not nose or py.test.
Besides instead of::
assert actual_result == expected_result
I think it's more sensible to write::
assert actual_result == expected_result, expected_result
but already that's excessive typing.
In general I get the feeling that assertEquals() and its companions ARE more useful in terms of output but I still stand by my opinion that writing them is disadvantageous in favor of assert.
Comment
If that test fails, you have no idea what the actual_result was, since you're only shown what it wasn't.
assertEquals( x, y ) will tell you "Foo" != "Bar", your test will simply say, "failed: Bar". Why did it fail? Being told why it failed usually saves me a minute or two, so I can squeeze more productive work into the time I have available.
Parent comment
People behind nose and py.test are clever cookies but unittest (which ZopeTestCase and Django TestClient is based on) is not nose or py.test. Besides instead of:: assert actual_result == expected_result I think it's more sensible to write:: assert actual_result == expected_result, expected_result but already that's excessive typing. In general I get the feeling that assertEquals() and its companions ARE more useful in terms of output but I still stand by my opinion that writing them is disadvantageous in favor of assert.