I had a post almost a year ago Hard Contracts vs Soft Contracts that was I reminded of when I came across this post on Testing with generic abstract classes. At our company we've been using the abstract test case pattern for a while, but have been struggling with naming... why not just call it FooAbstractTest you ask? Because, well, our build looks for classes that are named Foo*Test* in our test package and tries to run the abstract test cases and it breaks our build. So like any good software engineer instead of solving the problem, we just tried to work around it (sigh).
Anyway, we were struggling for a good naming convention, the best we could come up with was FooBase (terrible) but then as I mentioned I came across Mark's post, which in turn lead me to this wonderful page on c2 http://c2.com/cgi-bin/wiki?AbstractTestCases. The first line says it all, "Contract Tests" and really I knew it all along. I had been thinking of them in terms of hard contracts vs. soft contracts. So now I can feel good about myself and continue being a good software engineer, I have a better name, FooContract.
UPDATE - If you followed the link to the c2 page, you'll see that J. B. Rainsberger is referenced all over the place. Well he just republished his initial thoughts on the Contract Test. Also, if it wasn't clear, I was being very tongue in cheek about not fixing our build, we should do it, but finding a good name for these kinds of tests is also important.
2 comments:
Well, we had also been using AbstractXXXFixture... but in reality the test task needs to change...
oh yeah, I forgot we upgraded from XXXBase to AbstractXXXFixture. But XXXContract I think is perfectly fine. The word fixture never sat well with me because a test fixture refers to the state needed to run tests not the tests themselves.
and of course... I agree the test task should change. And I really like the use of the word contract. An abstract test class is really talking about a contract you must fulfill. If you'd like to be sure you're implementing everything correctly.
It being an Abstract Class is just an implementation detail. So, I still think they should be called XXXContract
Post a Comment