No, equals is a global test helper, not a method. The tests don't need to be unittest.TestCase instances; it merely reuses unittest's assertEquals because it already exists.
assertEquals is only "standard" if you're using unittest; beyond that, you're going to have to become familiar with the codebase's test helpers anyway -- try navigating through Django's or SQLAlchemy's tests. :)
You say it's simplified. Fine. If you didn't simplify wouldn't that then become:
def equals(self, a, b):
self.assertEquals(a, b)
return True
def test_foo(self):
assert self.equals(x.foo, "bar")
That looks pretty verbose to me. It doesn't make it any neater or simpler.
We have to recognize a benefit with using standard self.assertEquals() that it's kind of a "standard" in that every programmer uses the same. If you then have to debug someone elses code and that uses the non-standard equals() it becomes harder to read.
Comment
No, equals is a global test helper, not a method. The tests don't need to be unittest.TestCase instances; it merely reuses unittest's assertEquals because it already exists.
assertEquals is only "standard" if you're using unittest; beyond that, you're going to have to become familiar with the codebase's test helpers anyway -- try navigating through Django's or SQLAlchemy's tests. :)
Parent comment
You say it's simplified. Fine. If you didn't simplify wouldn't that then become: def equals(self, a, b): self.assertEquals(a, b) return True def test_foo(self): assert self.equals(x.foo, "bar") That looks pretty verbose to me. It doesn't make it any neater or simpler. We have to recognize a benefit with using standard self.assertEquals() that it's kind of a "standard" in that every programmer uses the same. If you then have to debug someone elses code and that uses the non-standard equals() it becomes harder to read.