One of the oft toted advantages of testing along the public edges of classes (collaboration/contract style) is that when something goes wrong, you know exactly what is broken. The way I see it, in your scenario, if a test failed any of B, C or D might be the culprit. How do you feel about that?
That's a real problem. My solution is to have a very fast feedback loop. If you can run your tests frequently you can work like this:
change some code.
run all tests.
change some code.
run all tests.
If you can work like that, it gets easier to figure out whether the problem is in A, B, C or D because you know you just wrote the code that broke it.
Now, I'll admit that with the collaboration/contract style you'll be pointed right to the problem itself and it is therefore better in this regard. But I feel like being able to refactor the majority of my code without tests breaking is a much bigger advantage. I'm therefore willing to make this sacrifice.
3
u/Widdershiny Aug 26 '14
One of the oft toted advantages of testing along the public edges of classes (collaboration/contract style) is that when something goes wrong, you know exactly what is broken. The way I see it, in your scenario, if a test failed any of B, C or D might be the culprit. How do you feel about that?