TDD improves the design?

Question

Some people say that TDD (Test Driven Development) is responsible for improving design of the project classes. Others say this does not happen or is not necessarily true. TDD by itself, without any kind of design preliminary, has evidence that actually produces a good design?

Brazilian version of this question: Does TDD lead to good design?

Answer 1

The very Uncle Bob who defends the TDD so much says what makes the design be good is the programmer. And I couldn’t agree more.

If the person thinks that TDD is silver bullet will go wrong. And it is common that people who most think this is what they use wrong.

Knowing how to do TDD can be useful. The problem is that to do right needs to be very good at understanding complex problems as a whole and looking at every little detail. If the person has the ability to do so is one who will benefit little from TDD, which is a paradox.

Testing

Let’s understand that testing is good. No one discusses it. And test for not work is even more important than testing to work, which is a minority it does. The vast majority of programmers only test to see working.

Unit tests do not let you make the same mistake again and have no regression. As a consequence there will be a little less bugs. But it’s not even close to making software bug free.

For me, unit and TDD tests serve different purposes although they used the same technique. Unit testing tests what you know needs to be tested. TDD tries to define what the project will be. But when you’re developing you realize that some things don’t work as expected. Then you change the TDD? So why did you do the TDD?

Does it help you think the problem? If you start with a prototype and get better it doesn’t make you feel the same?

There is no evidence

The fact is that there is no evidence that TDD is effective and even some old users today no longer use. If you feel comfortable with it, if you believe that it is helping, okay, good for that person. If the person wants other people to adopt TDD, they have to offer thorough proof that he is good. Everything there is about TDD says it’s good and you should believe it. It seems sect.

I’ve given an answer before that said TDD is good when you have a very well made clear specification. Rare problems are like that. Programming languages are. I don’t know a single programming language that has a compiler developed with TDD. They are software developed by some of the best developers you can find. Why did they choose not to use TDD?

Commuters

But I keep thinking how much design changes only to be able to make the code testable. This helps the design? Some say yes. I think it puts penduricalhos that do not serve the domain, which is the important part of the code.

I have seen code with 200 thousand lines that I would do in 10 thousand. No exaggeration. Because of the techniques of good design adopted. Which code do you think is easier to maintain?

Well, of course, it’s the technique being misused, but anyone who can’t program right will only get more complicated with more complex techniques.

To do TDD requires a design specific full of layers. You don’t always need these layers to solve the problem you have at hand. It is the developer working for his own problem and not for the problem he needs to solve.

I have no doubt that the TDD forces the developer to do the design that some people like. Hence say that this is good design need proof. Opinion everyone can have. So much so that I just think TDD is not a solution, but I’m not sure.

Develop need before solution is old

In fact a similar form was already made a long time ago and it was called programming top-down, which was the opposite of bottom-up. The first technique is doing what it needs at the highest level and is developing what is necessary to accomplish this, which is a very similar form of TDD. But creating a new technique would sell consulting, lectures, books, courses, etc. If you need to sell so much, I have doubts if it is good. What is really good people adopt easy.

Of course TDD requires much more.

Agile

To speak the truth TDD is an important tool in Agile. This methodology preaches that you should not plan too much, that everything should be easy to redo. I’m a bit critical of Agile. The idea is good. But I don’t see good results.

Everyone knows that development is the easy part, it is difficult to maintain, also because there will be a lot of maintenance and little initial development.

When you start putting too much penduricalho to facilitate maintenance can end up complicating it. When you try to do quickly what will consume 5%, 1%, who knows less than that, and creates difficulties for the rest of the work, it seems to me counterproductive.

In fact I’ve been observing projects open that adopt Agile, and some until they started to use Agile at a certain time being able to compare with the results when they were not Agile. Only projects high profile. I see a decrease in project productivity as time goes on. I didn’t see that much before becoming Agile. One of the reasons that before was more productive is that the design was more planned before.

Many of these projects begin to deny putting certain features because they do not fit the design started, and change this complicates too much. The product begin to suffer.

It is very common projects to be done by Agile and then it is for another team to give maintenance that in the end cannot give continuity to it and end up doing another.

More and more we see new projects competing with each other or that serve to kill an existing one because the initial engineering was wrong. The rewrite is the only way out, which a lot of people say is the last thing you should do.

At this point I actually like Agile, since I am one who thinks that all software has a lifetime. It may even change from now on because computing and software engineering may have reached a good maturity, but so far software with 3 decades, even if very well developed, carry a lot of legacy and are with impractical maintenance.

Starting to develop something is easy, maintaining is complicated. TDD no longer helps than doing unit tests that help the developer change with confidence.

Does this prove anything? No. It’s just my experience.

I’m not saying that Agile is bad and should never be used. Only that I have seen the projects drag on and on and on and off they start again because it has reached a point where maintenance has become unsustainable. That’s a truth that’s thrown under the rug.

Look, I’ve bought the idea of Agile before. I haven’t closed my eyes to it. Nor am I the guy who creates a stack of documents that specify the software. It’s a middle ground. To tell you the truth, I don’t even think the TDD has the face of Agile since it requires documenting too much.

Completion

It may be that some people can only think of the problem by doing TDD. Ok. It’s one way. But it’s not the TDD that did the design get well.

Everything I said here has the same credibility as the proponents of TDD. Very little. So you have to find what’s good for you. And preferably this should be done according to each project. I respect anyone who disagrees, but again, if the person wants me to adopt, present me with proof that it’s an improvement. I want to make sure he’s good.

You have an answer about that here: How to perform TDD on the Service layer.

More a complement.

Be sure to read link of the question and the duplicate marked there.

Passphrase:

How do you know what you don’t know? -- Peter Novig