At the Agile Singapore conference last year Steve Freeman spoke about the way TDD has been misinterpreted and frequently misapplied in many adoptions and how the SOLID architectural principles are still important, perhaps more important now than in the past.
After the conference InfoQ spoke to Freeman about his talks and the ideas behind them.
InfoQ: Your first talk was titled “TDD – that’s not what we meant”, why that title and what DID you mean?
It's a slightly provocative title to attract peoples' attention. It's really a "Back to Basics" talk about Test Driven Development, trying to remind people of the basic principles and explaining why I find it works for me. I wrote it partly in response to the "Is TDD Dead?" discussion that was going around a while ago and as my version of several talks on the same topic.
InfoQ: What’s wrong with the way TDD is commonly implemented recently?
In my training and consulting work I see a lot of teams that seemed to have missed the point. They have lots of test code that neither helps them found bugs nor explains the code under test. Often they were writing tests because someone told them to, but no-one had ever explained the purpose or practical technique. When people finally get fed up enough with this overhead, they either drop the tests or move on to the next popular technique. The point I was trying to make was that TDD, like any technique, only works when people understand its purpose and have had enough time to understand it. My one-line explanation is to think about what story the tests tell about the code. If you can't understand it, then either the code or the tests need to be improved, or possibly both.
InfoQ: Are there any common anti-patterns you can identify and what suggestions do you have for teams who are making them?
Most of the anti-patterns are around complexity and brittleness. One symptom of that is when tests become difficult to read, another is when it's impossible to make a change without breaking everything. The solution is to actually listen to the tests and respond to the back pressure they're providing. That might mean cleaning up the test so it makes sense, or breaking up the code into smaller units, or not trying to do clever things with byte-code manipulation.
InfoQ: How do teams make their code and tests a basis for a conversation with the future?
Did I mention making them read well? At the core of the practice is discovering a new test that is difficult to write. That's your design moment when you need to think about your current structure. Perhaps the test is telling you that the unit of code is getting too large, or that you need to expose more access for a new feature, or something else. The important thing is to stop and reflect, and maybe refactor, rather than just pushing on somehow.
InfoQ: Your other talk was “Building on SOLID foundations” – what are these foundations?
The title of the talk is a little confusing. The foundations are SOLID, Michael Feathers' acronym for object design heuristics. What we build on it are more complex applications.
InfoQ: SOLID is an idea that has been around for quite a while – how come it’s not been applied effectively?
The talk arose from an observation that we see many systems where the individual objects are fine but, somehow, the systems is hard to work with. We think that it's because of a lack of attention being paid to mid-level structures.
InfoQ: What can/should programmers do differently to truly build on a foundation that’s useful
The heart of the talk is that we should make composeability a first class concern that we think about when we code. Just chaining methods or having names with lots of words smashed together does not help us keep the code flexible. What does help is thinking about how to design our objects so that we can easily combine them to create new behaviour. Part of that is having a clear separation between code that defines behaviour and the state that passes through it. That's one of the good things that comes out of the new popularity of functional programming, and you don't have to be working in Haskell to get the benefit of compositionality.