One pattern I see over and over in tests is the assumption that the tests will always run to green. Now, you might think that's an odd statement right? I mean the whole point of tests is to make them run green, right? Well, in a way, yes. But, more importantly they are a communication device to help new developers understand your intentions. Too many times, I've seen assert statements that simply check a size of a collection. Sure, the tests pass, but what does that saw? Why that specific size for that collection? It's frustrating because when I see these things, it's obvious the developer never thought the code would break after the test was passing.
Think about it if I check that the size of a certain collection is 5. I can bet in 6 months the reason will be fuzzy. Of course, you could name the 5 as a constant and that would certainly make it more readable. It is a step in the right direction even. But, why 5? If I change code and I get back 7, what does that mean? A constant might help, but it might not. Be specific in what you check. Don't get lazy in naming or being general. Spell it out. It might take more effort now, but it will pay huge dividends when the test breaks. More than likely, when a test breaks after it is running that it is unexpected.
Feel sorry for the poor developer that has to change your code and then figure out your tests. Take as much care in your test code as your main code. You will be thankful later. Your tests will spell out exactly what's wrong, be easy to debug, and most importantly easy to be fixed again.
Subscribe to:
Post Comments (Atom)
1 comment:
Can you give a more specific example please? I don't see anything wrong with this, for instance,
| file |
file := self loadPaymentFile: self sample.
self assert: file validPayments size = 3.
self assert: file invalidPayments size = 1.
Post a Comment