7 ms·
> that tells us that we wrote a bad test, not that TDD is bad I strongly disagree. The only thing that matters to how software works for an end user is its bo
by sago 11y ago
> that tells us that we wrote a bad test, not that TDD is bad
I strongly disagree. The only thing that matters to how software works for an end user is its boundary. You simply can't do TDD by only testing the boundary.
You have to write a test before each unit of code, so you have to test those internal interfaces, the way units of code work. But that is exactly the stuff that should be allowed to change. It's a mistake to assume 'implementation details' only exist within a function. That stuff you can avoid testing, but the behavior of the function is itself an implementation detail for whatever is using that function.
I simply cannot imagine TDD for anything other than a toy example where you don't end up writing tests that depend on the software's implementation, and are therefore inertia to changing that.
> we should be just as ruthless in refactoring and peer-reviewing each others tests
I strongly agree. But this is rarely part of the TDD ethos. Saying "I refactored the code and threw away 100 tests." is likely to send TDD folks twitching, in my experience.
- mbrock 11y agoChanging tests is work, yes. Unit tests are precisely about verifying implementations, and maintaining them is the price you pay for having these layers of verification. It's inertia in the way a safety net is a barrier.
- hinkley 11y agoI have always found the 'safety net' analogy uninspiring, and people who think they're tough and manly don't need safety nets, thankyouverymuch. Now, safety equipment in a race car is something else entirely. Half of it keeps you from dying immediately on impact, sure, but the other half actually lets you go faster. The 5 point harness, for example, helps keep you from losing control of the vehicle during high G maneuvers, by keeping your torso in the seat and therefore your legs and arms in (roughly) the correct orientation to the steering wheel and the pedals.
- firepoet 11y agoNot this TDD folk. :-)
- RHSeeger 11y ago> The only thing that matters to how software works for an end user is its boundary. You're ignoring the fact that tests aren't only to validate "end user functionality". They're also there to make life easier for the developer; to make both initial development and maintenance easier. If I need a custom sort algorithm for my product, I'm going to write unit tests for it's implementation. I'm also going write functional tests to make sure the end user is seeing things sorted. However, those tests serve different purposes. The unit tests allow me to write clean, simple tests that show exactly what the implementation is supposed to be doing for different inputs. That allows me to change the implementation of the sorting algorithm later and worry less about breaking the functionality. The functional tests are (generally) not going to be as clean and obvious, nor cover every possible partition of inputs that the implementation could get.
- sago 11y ago> You're ignoring the fact that tests aren't only to validate "end user functionality". Erm, no, that was my entire point!
- RHSeeger 11y agoWow... um... you're right. I was flitting around and dealing with external communication at the same time; you have my apologies. I think my points align pretty well with what you were saying instead of against it.
- sago 11y agoThanks for the response, it's fun to read someone strongly disagreeing while saying what you think. slightly baffling, but fun ;)
- agentultra 11y ago> If I need a custom sort algorithm for my product, I'm going to write unit tests for it's implementation. I would start with writing an assertion about the end state of the sort. Then using syntactic substitution of the predicate calculi derive the program by assertions. I'd then have a specification of the algorithm as a mathematical model from which I can check every possible execution for the entire domain on the sort. If I'm so inclined I would have a good basis for a proof. The unit tests then become assertions on the implementation and don't have to verify correctness. It would be awesome though if I could just generate the code directly from the specification!
- oldmanjay 11y agoI have used TDD to construct many production systems. Your lack of imagination is not a particularly compelling basis for an argument.
- sago 11y agoYou're disagreeing with my 'I can't imagine'? So you're saying you've built non-toy systems with TDD where you've never tested anything but the user-facing behavior of the system? I'd be interested in knowing how, and what kind of thing you build. I can almost imagine it for an API or framework, where almost every implementation choice is on the boundary. But even then, you have to test private functions to do TDD, surely. I work on real time stuff, and in that stuff, the user-facing functionality is hard to test, and usually not tested in a TDD kind of way. The TDD stuff is all internal.