Home/ Questions/Q 610435
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-13T17:40:30+00:00

I recently finished a project using TDD and I found the process to be

  • 0

I recently finished a project using TDD and I found the process to be a bit of a nightmare. I enjoyed writing tests first and watching my code grow but as soon as the requirements started changing and I started doing refactorings I found that I spent more time rewriting / fixing unit tests than I did writing code, much more time in fact.

I felt while I was going through this process it would be much easier to do the tests after the application was finished but if I did that I would of lost all the benefits of TDD.

So are there any hits / tips for writing maintainable TDD code? I’m currently reading Roy Osherove’s The Art Of Unit Testing, are there any other resources that could help me out?

Thanks

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Practice

    It takes a while to learn how to write decent unit tests. A difficult project (more like projects) is nothing strange.

    The xUnit Test Patterns book recommended already is good, and I’ve heard good things about the book you’re currently reading.

    As for general advice it depends on what was hard about your tests. If they broke often, they may not be unit tests, and more so integration tests. If they were difficult to set up, the SUT (System Under Test) could be showing signs of being too complex and would need furthering modularisation. The list goes on.

    Some advice I live by is following the AAA rule.

    Arrange, Act and Assert. Each test should follow this formula. This makes the test readable, and easy to maintain if and when they do break.

    Design is Still Important

    I practice TDD, but before any code is wrote I grab a whiteboard and scribble away. While TDD allows your code to evolve, some up front design is always a benefit. Then you at least have a starting point, from here your code can be driven by the tests you write.

    If I’m carrying out a particular difficult task, I make a prototype. Forget TDD, forget best practices, just bash out some code. Obviously this is not production code, but it provides a starting point. From this prototype I then think about the actual system, and what tests I require.

    Check out the Google Testing Blog – this was the turning point for myself when starting TDD. Misko’s articles (and site – the Guide to Testable code especially) are excellent, and should point you in the right direction.

    • 0