This is the kind of stuff that in the aggregate you can't show a relationship, but I bet if you controlled for type of project one would see some interesting results. Anecdotally, I know some firmware engineers that shit out the buggiest code I have ever seen, and test driven development would have definitely improved the customer experience. Because when the engineers have literally no tests other than trying stuff out with a printf on the target embedded device, any amount unit-testing will wind up helping.
An External Replication on the Effects of Test-driven Development [pdf]
21–30 of 332 posts
Re: An External Replication on the Effects of Test-driven Development [pdf]
#22As someone who uses unit tests to find bugs in my code, that I would never otherwise find, this is surprising.
[deleted]
Re: An External Replication on the Effects of Test-driven Development [pdf]
#23It may not boost productivity upfront, but it saves a lot of time down the line by alerting you when something is out of place.
No, that's the value of automated regression test. TDD is just one way to skin that particular cat.
And that test winds up in v0.1.1 of your software magically, or is it there because you put it in the work to add it up front?
Re: An External Replication on the Effects of Test-driven Development [pdf]
#24Tests before/at/near development time really helps your code design - I've seen how ensure code is unit testable simplifies and enforces layering, etc. Really disagree that this does not help code quality.
Re: An External Replication on the Effects of Test-driven Development [pdf]
#25Could 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…
For me it's a highly situation-dependent thing.
Sometimes writing tests first helps me think about the high-level design of my code. Other times I've got to try a few things before I have any idea what the code should look like, and writing tests first would just create a lot of extra code churn. I feel that, as time goes on, I'm getting better at anticipating which situation I'm in. I also switch back and forth between the two testing methods even more rapidly.
Re: An External Replication on the Effects of Test-driven Development [pdf]
#26[deleted]
Re: An External Replication on the Effects of Test-driven Development [pdf]
#27Earlier 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…
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.
Re: An External Replication on the Effects of Test-driven Development [pdf]
#28There 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.
Re: An External Replication on the Effects of Test-driven Development [pdf]
#29...when implemented poorly
Therein lies the rub with all the faith-based modern development practices. Getting results? That's the power of The Practice. Not getting results or seeing negative impact? You're just not doing The Practice right and/or hard enough.
Re: An External Replication on the Effects of Test-driven Development [pdf]
#30As someone who uses unit tests to find bugs in my code, that I would never otherwise find, this is surprising.
That not TDD, though. It's more similar to test-after.
I think test after is a reasonable approach. I am constantly dealing with new code bases and in the interview process I am often asked about my philosophy about testing. My response is thatbtrsting occurs on two fronts from the top down ( functional UI tests) and from the bottom up (unit tests). When it comes to unit testing my approach is to focus on the hotspots. If something gives you trouble, or if you find a bug/ issue then wrap it in a unit test. That way you don't have to worry about it. Bugs tell you where the weak spots in your code base are. When they speak to you, listen and take some action. Otherwise, I feel like chasing blanket coverage is not worth the effort in most products.