Both nose and py.test encourage just using "assert" because it is more pythonic. However the nice thing of self.assertEqual() and friends is that you don't have to write the message yourself to get a nice message in case the test fails. That's why both nose and py.test do try to show the values of the objects involved in the assert statment, relieving you in most cases of having to write the message yourself.
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.
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.
Comment
Both nose and py.test encourage just using "assert" because it is more pythonic. However the nice thing of self.assertEqual() and friends is that you don't have to write the message yourself to get a nice message in case the test fails. That's why both nose and py.test do try to show the values of the objects involved in the assert statment, relieving you in most cases of having to write the message yourself.
Replies
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.
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.