TDD ideally is just “enough design up front” and then you are NOT limited to your initial design decisions which would have been made when you knew least about the module being implemented.

The refactoring provides the freedom to always permit more optimal designs to emerge as you discover more about the nature of the requirements being implemented and the best way to implement them.

Doing TDD well is an art to be learnt in itself with practice and mentoring.

TDD doesn’t negates the need for an application architecture that is concerned with the bigger aspects of the system. It is about design of the more granular pieces that make up the software.

Also TDD seems like a bad design choice. We start writing code with no idea of design in place until after countless refactorings a design is somehow discovered.

This voyage of discovery seems somewhat wasteful.

The SOLID acronym so the new darling of alt.net. I’m waiting for a post saying there is no excuse not to write code that does not adhere to SOLID.

I often hear the TDD is design argument which seems to contradict what most have previously stated. It is often quoted that you need tests in order to refactor. This would lead you to believe the tests are indeed there to TEST nothing has broke during the refactoring.

Also TDD seems like a bad design choice. We start writing code with no idea of design in place until after countless refactorings a design is somehow discovered.

This voyage of discovery seems somewhat wasteful.

The SOLID acronym is the new darling of alt.net. I’m waiting for a post saying there is no excuse not to write code that does not adhere to SOLID.

My experience is that where I have been and the excuse to not invest in quality practices such as TDD is a lack of time because of deadlines. It is the most compelling argument for investing in TDD.

Quality can NOT be bolted onto a product by additional QA testing at the end. Quality must be built in by the use of quality practices and tools. A significant characteristic of quality is that is closes the feedback loop as early as possible and as often as required. Automated testing such as that produced as a result of applying TDD and automated user acceptance testing meets these quality characteristics perfectly.

Where we have relied on QA testing to close the feedback loop many loops are being closed a long time after the code was written and many loops are being closed all at the one time, resulting in many raised bugs to resolve, when we least want the stress in the development – test – release cycle for an application release.

Many developers can see the benefits of the growing suite of unit tests as a result of applying TDD as being a powerful regression tool. They find difficulty in understanding that TDD’s real value is as a powerful object-oriented design tool that via continuous refactoring continuously permits more optimal designs, conforming to SOLID principles, to emerge as the developer continuously discovers more about the nature of the requirements being implemented and concurrently simpler and more elegant designs for implementing them. Where we have relied on QA to essentially “clean up” after us fixing each bug has often resulted in unknowingly creating several others as there has been little or no attempt at implementing separation of concerns, a real circus.

Applying TDD is a powerful communication mechanism for determining exactly what are the requirements to be implemented. The tests are a black and white, pass or fail, explicit view of the expected behaviour of the module being implemented. The automated tests are executable documentation. It drives out all forms of ambiguity in the requirements or the developer’s interpretation of the requirements. Business analysts have always appreciated the fact that I will be persistant in working with them in teasing out the exact meaning of the requirements as it provides invaluable feedback to them that I have understood the requirements and where needed they have gone back to the business for clarification where required. Business analysts worst nightmare is where the developer does not understand and has made their own assumptions where there is ambiguity.

Delivering business value in software development boils down to building the right thing (the optimal requirements that deliver business value to the user) and building the thing right (the optimal design). TDD, along with other forms of automated testing, is such an important enabler and verifier in being able to build the right thing and to build it right.

Maybe some words from the lead developer/architect’s point-of-view to this. In teams with limited resources and/or limited timeframes, you’ve to decide for the important things. First, the functionality you’ve to deliver, second the documentation quality (Javadocs, etc.) for later maintenance, third all the modern extras, like TDD. I can skip unit tests if I test on a higher level (e.g. the user interface). This is what the elder did in the past. And it worked with the right testing teams.

And the real question to me is what do I loose not following the TDD ideas? I don’t think its stability. If the test team is smart, this is no problem. Maybe flexibility in changing or extending existing code. Some bugs will be found later. But, what does this cost me in the end? Basically, I’ve to be more careful with my interface designs and have to invest more time in pre-planning.

With limited resources and limited time frames I can’t expect to get extra time for refactoring. So, the design has to hit the target earlier anyway. I’ve no problem to invest more time in design, and skip unit tests. Maybe not modern today, but it worked in the past.

Some words about my experience with the team. All developers love to write unit tests. It’s ok to me. I’m the opposite to the lead developer m4bwav mentioned. I even change my designs if the arguments show that my ideas doesn’t deliver the best result the team can produce:

http://blog.rainer.eschen.name/2008/02/20/the-mission-of-a-software-architect/

But, it’s not enough to be motivated. There are a lot of young developers in the team. Lack of experience, not only in TDD but also in software engineering principles, is a big point here. So, the more tests we have, and the more customizable (and complex) the implementation gets, the lesser useful the unit test are. Even continuous integration gets worser.

So, what’s missing here (and that was not mentioned in this post)? Planning. TDD needs time to be successfully implemented. I think the developers try to follow all ideas of this post, but that’s not the point. Only the quality of the unit tests result is important. This quality is not for free. We don’t get it automatically. And it’s a hard job to get it. Looking back the last years I think even without limitations TDD is only successful if your functional design is extended with a test design.

Provocation: is it really worth the effort, or is TDD only a hype? Any studies? Nobody is question the efficiency anymore.

http://the-software-simpleton.blogspot.com/2009/01/assertthattdd-istrue.html

If the deadline is too tight, and the lead developer is not at all familiar with TDD, then your kind of f**ked.

I would like to refactor the code to make it more testable, but the lead developer would both be concerned about the time I’m taking because they wouldn’t really care what it was for, and because I would be altering their poor design. Many lead developers are defensive about their position, and wouldn’t like someone upstaging them by refactoring the code for reasons they don’t understand.

I love TDD, but I think TDD advocates forget that teaching TDD, and it’s concepts takes time for those unfamiliar to them. And in time deadline situations, especially with rookie leads, it’s going to be hard sell.

While I agree that you should always test and there is no excuse for it. Another thing that really effects testing is getting legacy code under test. Sometimes the technical debt is just too great to get old code under test.

From the aspect of new development however, I agree completely, there is no excuse for leaving out tests.