An External Replication on the Effects of Test-driven Development [pdf]

Actual studies were never needed to convince managers to switch processes. Bonus points for blaming old problems on old process while blaming new problems on "not doing agile right".

Re: An External Replication on the Effects of Test-driven Development [pdf]

#5

Post by geerlingguy » Wed, Oct 19, 2016, 3:06 AM UTC

Could 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 more about scenarios first, then code after they have everything accounted for. For them, TDD as a philosophy seems more fitting.

I think the chasm exists between _untested_ code and code that has tests. I've never understood the seemingly-religious zealotry behind TDD as an XP practice. Just like pair programming... 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.

Re: An External Replication on the Effects of Test-driven Development [pdf]

#6

Post by isuckatcoding » Wed, Oct 19, 2016, 3:07 AM UTC

As someone who uses unit tests to find bugs in my code, that I would never otherwise find, this is surprising.

Re: An External Replication on the Effects of Test-driven Development [pdf]

#7

Post by barbs » Wed, Oct 19, 2016, 3:08 AM UTC

geerlingguy wrote: post #5

Could 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...

Re: An External Replication on the Effects of Test-driven Development [pdf]

#8

Post by problems » Wed, Oct 19, 2016, 3:08 AM UTC

djrtwo wrote: post #3

micahbright wrote: post #2

Somehow, as a Software Engineer, I'm not really surprised.

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 but it's more a motivational tool and a productivity simulator (yay look at those green checkmarks!) than a real benefit.

The end result is identical, this sort of craps on it as a motivational tool too if you consider that only as a factor in development time at least. It'd be interesting to see developer satisfaction included in some way too.

Re: An External Replication on the Effects of Test-driven Development [pdf]

#9

Post by refulgentis » Wed, Oct 19, 2016, 3:08 AM UTC

My anecdata matches the author's - I feel more productive doing TDD.

Perhaps because it's less stressful. You think about system design as you code, instead of only when you hit a wall and have to rewrite everything, or when you have to clean up for code review.

Either way, if it has little to no compact on dev team or code quality, I bet the positive impact TDD has on team morale would make it worthwhile.

Re: An External Replication on the Effects of Test-driven Development [pdf]

#10

Post by zzalpha » Wed, Oct 19, 2016, 3:09 AM UTC

djrtwo wrote: post #3

micahbright wrote: post #2

Somehow, as a Software Engineer, I'm not really surprised.

Can you elaborate?

Well, let me ask you:

Why would we assume TDD would improve code quality or development time?

If, at the end of the day, the result is the same volume of tests and the same level of overall coverage, the order of activity would seem to make no difference. What would lead you to believe otherwise?

The real flaw in both methodologies is that it's the developer checking their own work.

I'd make the claim that if you really wanted to do it "right", you'd have a specification, one developer writing tests to the specification, and a different developer writing the code to make the tests pass.

Of course, that's probably not workable in practice... make for an interesting experiment, though (and yes, I'm too lazy to search Google, only to discover someone else already came up with the idea).