A colleague from Italy asked me for my opinion about this piece from TechCrunch, You’ve Got To Admit It’s Getting Better. This is a post related to the now infamous rant from Ryan Dahl of Node.js fame about the status of software in general, and how different layers of code and components integrate in particular. Rather than an harmonious dance of well balanced and fine tuned libraries, Dahl is right to point out that quite often we work with layers and layers of complexity and leaky abstractions which end to expose, most of all, an annoying dissonant impedance mismatch. While I partly agree with Dahl, I have to admit that also Jon Evans of TechCrunch has a valid point: it’s getting better, not enough probably, but better.
What has caught my attention more is something else though. I’m pretty sure that my friend asked me about this because of some unkind words for TDD. So let me get the record straight:
- First of all, it’s just wrong to say that TDD is “the notion that a development team’s automated tests are even more important than the actual software they write, and should be written first” (Jon Evans himself) => no TDD practitioner in his right mind would describe TDD in that way. In particular, nobody would consider the tests more important than the actual software. So, yes, we TDDers think that testing is important, because for us testing is first of all a design technique and tests are a nice byproduct of this technique, one that allows you to evolve your code without breaking existing behaviour in an uncontrolled way. But none of us would try to say that tests are more important, please! If you write about something that is clearly not your forte, at the very least you should not make such a gross mistake.
- I don’t know where I’ve lived in the last 10 years, but TDD has never “seemed almost sacrosanct” (Jon Evans again). I’d argue that still only a minority of developers actually test their code in these days. TDD practitioners then are a minority of a minority. So, please, spare me the drama about the industry changing its mind about TDD.
- With regards to the two linked posts, I have to confess that I have no idea who are the authors. That doesn’t necessarily mean anything per se, just that I don’t have any prejudice about the authors. I’ve never read anything from them before.
- Pieter Hintjens seems to recommend that rather than testing your code, you should throw it out in the open and have people (users) testing it for you. It seems that his main argument is that, even if you think you know how to test your code, you don’t know if your code is valid in the hands of users. Apart from the fact that it doesn’t seem a very professional approach, this is mostly nonsense to me: testing and validation are two different things. Sure, you need your software to do something useful for your users, otherwise it can be correct but it would be of no purpose at all. So, assuming that your software solves the right problem, how do you know that it solves it correctly? Testing to the rescue. In the end the author even admits that he uses TDD for his APIs…
Having said that, remember that TDD is first of all about design and evolution. So I think that this point is totally wrong.
- Peter Sargeant rants about dogmas and Agile Testing Experts recommending to always write your tests first. The term “Agile Testing Expert” is funny enough already: there are no such people, there is no agile testing, thank God at least there is one aspect of XP that the Agile crowd has not been able to jeopardize with their brand (oh, they tried, but they also failed miserably – some people cover TDD, BDD, ATDD and other practices together under the umbrella of Agile Testing, but it seems quite fictitious to me and it has never been accepted in the community in that way). So, if you talk about Agile Testing Experts I’m already suspicious. Once again, this post seems to miss the point of TDD: it’s about design and evolution, testing is a collateral, an important one but still a collateral. Do I always write my code following TDD? No, I don’t. I rarely use TDD if I’m spiking or prototyping. I never use TDD for one off pieces of code that won’t survive to see the light of a new day. I very rarely use TDD for pure UI code, especially when it’s about HTML and views and layout and CSS… (you get what I mean I guess). And I never use TDD when I don’t know what I’m doing, when I’m exploring.
Anyway, Peter Sargeant’s blog is in the end about promoting testing automation, so his rant is more about breaking away from dogmas and using your head to judge when to use a tool, so it doesn’t seem to me to be such a big deal.
In conclusion, yes, things may get a little better and no, I don’t think that there is a whole movement against mainstreamed (!!) TDD in the software industry.