I’m in transition from “writing unit tests” state to TDD.
I saw as Johannes Brodwall creates quite acceptable design from avoiding any of architecture phase before. I’ll ask him soon if it was real improvisation or he had some thoughts upfront.
I also clearly understand that everyone has experience that prevents to write explicit design bad patterns.
But after participating in code retreat I hardly believe that writing test first could save us from mistakes. But I also believe that tests after code will lead to mistakes much faster.
So this night question is asking for people who is using TDD for a long time share their experience about results of design without upfront thinking. If they really practice it and get mostly suitable design. Or it’s my small understanding about TDD and probably agile.
1
From experience:
TDD does not necessarily lead to good design. It’s possible and really easy to get poorly designed program using TDD.
TDD is just a tool to help us design faster using refactoring, it will never make the design of the program appear magically. TDD is a design help tool. The quality of the design you will get out of TDD depend largely on the capacity of the developer to use refactoring to Design Patterns, or refactoring to SOLID principles.
The developer will make the design emerge using continuous refactoring. It’s the most important aspect of TDD: Refactoring.
Applying TDD without doing constant refactoring will often lead to really poorly designed systems which is worst than applying BDUF.
TDD is often associated with the notion of “emergent design“. In agile, you often build your software incrementaly, feature by feature. So you can’t know right from the start what architecture you will need, it will evolves/emerge with time. So any time you add a new piece of functionality you do some refactoring to improve the design of your application. It’s continuous/incremental design. That’s why TDD is key in a agile processes.
BDUF is not incompatible with TDD. There is nothing wrong with starting a piece of sofware while having the design already in mind. TDD will then enable you to put that design in place quickly. And in the case the design you thought about was wrong, TDD will allow you to refactor it nicely and safely. Again, it’s just a tool, it’s there to help us develop our ideas faster and design stuff safely and faster.
So you can either do BDUF+TDD or Emergent Design+TDD, the later is the more common in the agile community because of the iterative way of working.
In all cases you should never try to do emergent design without being willing to do some constant refactoring, they both go together and It does really requires a lot of discipline. Things can quickly spin out of control if you keep adding new features without applying Refactoring.
Refactoring apply to both production code and test code.
An interesting article to read to get more insight on the question can be found here:
Learning From Sudoku Solvers
2
It all depends on how your programmers are thinking:
- If they’ve used TDD before, then there is a chance of getting good design
- If TDD is being imposed from the outside, then it can only break the existing pattern your programmers are comfortable using
- On the other hand, the team should use common patterns so that everyone is creating part of the same design instead of randomly going to different directions
So it’s a balance between how disruptive process you want to impose and how much you can trust programmers to use their own techniques to create the best possible design. Getting feedback on how broken the previous code was is a good quality metric for programmers.
1
Definitely, TDD leads to better design, TDD leads to better code quality, TDD leads to better maintainability of code.
But, TDD does not help to create bug-free code, in the same way it does not provide good design.
For me TDD is the way to solve the problem a bit faster, that’s it. Maybe because I’m a bad upfront thinker. It’s easier for me to start with some ideas and shape it up with tests a bit later.
TDD does not guarantee good design at the end of the day. As you mentioned, the ‘Game of life’ could be great example. I’ve implemented it once with pure TDD. Everything was great as soon I had a bunch of unit tests. But after I implemented some UI and tried to run the game on a 64×64 grid, it turned out that performance of the application completely sucked. That meant I had 100% code coverage – but the app would not fly in production. This case could easily be projected on some projects we work in office.
So, I prefer another approach. Let’s call it post-prototype design. As soon as I have some working code with TDD (or not) I start to understand the task better, start to see different ways of implementation. I could spent some time with a piece of paper to find some design ideas. After that I can start the task from scratch, or re-use already created unit tests to implement those ideas.
4