TDD no, regression testing yes.
An External Replication on the Effects of Test-driven Development [pdf]
41–50 of 332 posts
Re: An External Replication on the Effects of Test-driven Development [pdf]
#42This is a misleading title and conclusion. The study showed a huge benefit of TDD over Waterfall, and it is only when compared to ITL that it was found to not be better.
But moreover, I think it's important to understand why Beck pushed for TDD.
TDD is like saying "I'm going to floss before I brush every time, no matter what."
But, when people don't do TDD they typically aren't all saying "I'm going to brush and floss afterwards every time, no matter what."
Instead, most say "I'll floss regularly at some point, but I don't have time now, and it takes too much effort. I'll floss here and there periodically, maybe before my monthly meeting or big date night."
Another reason Beck pushed for TDD was method and solution complexity reduction which results in lower time and cost required for maintenance because code is simpler to read and understand. Again, with ITL, you're still writing tests for everything, so you'll see those benefits. However, if you fail to write some or most tests, some developers will write overengineered solutions to things and have overly long difficult to follow methods that will make maintenance suck more resources.
If you want to go beyond this study, though, Beck, Fowler, and DHH had a critical discussion about TDD in 2014 that's worth checking out:
Re: An External Replication on the Effects of Test-driven Development [pdf]
#43TDD is king when refactoring, or proving an algorithm. You have a tests to confirm the output, and near realtime feedback that you assumptions are correct. The rest is obvious. Mission critical component TDD, complicated refactor TDD, algorithm you need to validated TDD. Anything else write the code and get a peer review.
Re: An External Replication on the Effects of Test-driven Development [pdf]
#44There is a problem with all these studies - they all use a very small amount of programmers (21 in this case) with no experience (all graduate students in this case) and presumably no significant experience with TDD or TLD. I'm not making a stand about TDD here - I just think we need to have much better computer engineering science studies if we want to have significant results.
Agreed. I also would question the short time scale of the test. It took me a year or so to really get good at test-driven development.
I also think of TDD as a sustainability practice. If I'm writing a small thing that I do not intend to maintain, I won't bother with TDD (or with tests at all). But I'll definitely TDD something where I expect to come back to it frequently, especially when I initially don't know the requirements, and I expect requirements to change over time.
In practice, I suspect a lot of the interesting questions about software are effectively unanswerable with the budgets available to CS profs. I can't imagine really answering this question without doing something of the scope of a substantial medical study.
Re: An External Replication on the Effects of Test-driven Development [pdf]
#45TDD, like most of the agile practices, is a learned skill.
Doing it at an expert level is very different from an untrained novice winging it.
Re: An External Replication on the Effects of Test-driven Development [pdf]
#46The title suggests that TDD has little or no impact on dev time or code quality at all.
The research shows no significant difference between TDD and iterative test-last (ITL) development.
Could the title be updated? To show that it is a comparison of TDD vs ITL/TLD.
Re: An External Replication on the Effects of Test-driven Development [pdf]
#47Earlier quoted context omitted.
Can you elaborate?
If you write testable software and actually write the tests, the end result is the same whether you test first or test later. You're designing with testing in mind and creating useful tests either way. It's really a matter of code that lacks tests that's an issue and especially of code which isn't designed with testing in mind. I think they overinterpreted the value of TDD as simply test-first. Test first can be good…
> If you write testable software and actually write the tests, the end result is the same whether you test first or test later.
This is definitely not my experience. As Kent Beck says, TDD is a design technique. It forces you to always start thinking of the code from the outside of the unit. If I build the unit first and add tests later, it's more likely I'll end up with something where the API reflects the implementation. With test last, I'm also less likely to test everything well; after the implementation is done, I believe it works.
Re: An External Replication on the Effects of Test-driven Development [pdf]
#48Could it be that TDD vs. tests-after-code is a highly personal thing? I personally find it easier to write good tests after I've coded something functional. Before hand, I know one or two fuzzy ideas of what I want to accomplish, but I can't list out the concrete, real-world test scenarios until after I've coded something, poked and prodded it, etc. But I know some people are wired differently; they'll think a lot mo…
> they'll think about scenarios first, then code after they have everything accounted for.
I'm one of those people. But I find it hard to believe that a test suite can reflect everything I understand about a problem domain. Focusing too much on unit tests makes it difficult to find the general rules that govern the behavior of a system. Have too few unit tests, and they won't capture all the subtleties and corner cases. Have too many unit tests, and they won't fit in your head.
Re: An External Replication on the Effects of Test-driven Development [pdf]
#49Earlier quoted context omitted.
If you write testable software and actually write the tests, the end result is the same whether you test first or test later. You're designing with testing in mind and creating useful tests either way. It's really a matter of code that lacks tests that's an issue and especially of code which isn't designed with testing in mind. I think they overinterpreted the value of TDD as simply test-first. Test first can be good…
I have always worked in a "test last" mode. That's the way I learned to program. Write some code, test it. When it works, write some more code, test some more. My attempts to work in a TDD style ran up against decades of intgrained habits and I never really found it satisfying or natural.
It took me a year or so to make the transition. And I think the transition is easier to make in a greenfield or already-TDDed code base.
That's not to say that you should try it again; I like TDD a lot myself, but software methods are so interdependent that I think each person has to judge what works best for them.
Re: An External Replication on the Effects of Test-driven Development [pdf]
#50Could it be that TDD vs. tests-after-code is a highly personal thing? I personally find it easier to write good tests after I've coded something functional. Before hand, I know one or two fuzzy ideas of what I want to accomplish, but I can't list out the concrete, real-world test scenarios until after I've coded something, poked and prodded it, etc. But I know some people are wired differently; they'll think a lot mo…
> if it works for you and your coding style, awesome. But don't force it down my throat or act like it's the One True Path to clean code. This applies to so many things in Software Development - text-editors, variable names, plugins, architectures, operating systems...
nope - vim