3 ms·
This is one thing that has irked me a little bit as I've gotten more involved with TDD and unit testing in general: the logic in many of my unit tests is near d
by prawks 13y ago
This is one thing that has irked me a little bit as I've gotten more involved with TDD and unit testing in general: the logic in many of my unit tests is near duplicate logic that is implemented within my application.
My thought is that the general advantage of TDD is that you are thinking about your eventual implementation from the outside. You write tests in a different mindset based on expectations, rather than when you are implementing the production code where you are more concerned with the details of logic, etc. Unit tests also tend to be a bit more readable than the actual implementation logic, and so act as a nice form of documentation as a side-effect. In this way, test-first development provides a more gradual transition between a specification or design and the end implementation, which results in fewer missed requirements, allows for easy refactoring, etc.
This is of course only related to TDD however, not unit testing in general. Hence, it still irks me that many of my tests look so similar to the logic they are testing, and thus aren't really testing for correctness at all.
- jacquesm 13y agoThink of unit testing as auditing the contract between two pieces of code right at the interface by replacing one of the two pieces of code (usually the client or caller but you can replace the code that provides the response just as easily) by a program that exercises the other layer. Like that you build your confidence layer by layer and with every set of tests you verify that you are still building on solid ground instead of quicksand. That's why you test at the interface level, it allows you to swap out the implementation without having to re-work all the test code.
- tieTYT 13y agoI went through a phase of this when I started writing automated tests. It occurred when I started using a mocking library for the first time. The library was so advanced I could basically test my implementation instead of my api. EG: "first you call foo.bar(), then you call foo.baz()" As a result, my test and my system under test looked very similar. I'm not sure if you're in the same situation I was in, but let me tell you: My situation was an anti-pattern. All I was testing was that my code does what it does. I wasn't testing that my code was working. Make sure you're not making the same mistake. If you are, a symptom would be that lots of tests fail when you're only refactoring.
- prawks 13y agoNot quite, but I get what you're saying for sure. I think jacquesm said it well in his reply to me that you're more testing the "contracts between two pieces of code right at the interface", and it shouldn't be any deeper than that to avoid what you're describing. The symptom of many tests failing during refactoring is something I'll be keeping in mind, however.