35

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.

Improve this question
1
  • 2
    +1. Interesting point which is never mentioned when discussing TDD. This being said, TDD doesn't exclude upfront thinking about the architecture, since it's more granular and concerns single methods rather than the overall architecture.
    – Arseni Mourzenko
    Dec 10, 2012 at 1:44

3 Answers 3

Reset to default
38

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

Improve this answer
2
  • 1
    "It will never make the design of the program appear magically" - I disagree; IMO one of the strengths of TDD is that you can "design by testing". Using a refactoring assistant like ReSharper or CodeRush, you can start coding the test as if the code you were about to write already existed. This first gets you to think about how you want to use the class you're about to develop (and ease of consumption is usually a key factor in design).
    – KeithS
    Dec 10, 2012 at 18:02
  • Now, half your code is underlined or highlighted in red because the objects it refers to don't exist. A few presses of Alt+Enter solves that. You have now "designed by testing"; you have the skeleton of the design you want based on your intended usage, within which you write the code that exhibits the behavior your test will expect.
    – KeithS
    Dec 10, 2012 at 18:04
0

It all depends on how your programmers are thinking:

  1. If they've used TDD before, then there is a chance of getting good design
  2. If TDD is being imposed from the outside, then it can only break the existing pattern your programmers are comfortable using
  3. 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.

Improve this answer
1
  • No, no. I talk personally only about me
    – Eugen Martynov
    Dec 10, 2012 at 12:46
-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 64x64 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.

Improve this answer
4
  • 1
    Alex, I didn't expect answer - yes it leads to 100% good design. I was asking experience guys who is using TDD for long time if it really tends to have good/suitable for current requirements design without upfront thinking
    – Eugen Martynov
    Dec 10, 2012 at 12:49
  • 1
    The answer was that TDD helps to fail faster with bad design as well it helps faster to change design to better by refactoring. So there is no straighforward connection between TDD and design
    – Eugen Martynov
    Dec 10, 2012 at 12:51
  • When writing Game of Life, shouldn't at least some of the tests be able to test for execution time? It is a demand of the program to be run in decent time, isn't it?
    – Ziv
    Dec 19, 2012 at 6:15
  • your Game of Life example is purely anecdotal evidence and provide no proof whatsoever
    – denis631
    Oct 26, 2019 at 20:02

Not the answer you're looking for? Browse other questions tagged or ask your own question.