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

Re:An External Replication on the Effects of Test-driven Dev... by problems on Wednesday October 19, 2016 @12:17AM (#12741032)

Perhaps it depends on how you implement each. If your idea of test last is writing a full large module and then trying to test that all at once, you might wind up with a different result than if you wrote an individual function or two and tried to test only those at once.

Getting the testing as close in time to the implementation as possible probably makes a bigger difference than first vs last.

[ Parent | on HN ]

Re:An External Replication on the Effects of Test-driven Dev... by wpietri on Wednesday October 19, 2016 @10:26AM (#12744051)

I definitely agree with that. If there is somebody who actually writes a few units of production code, a few units of test code, and then refactors, then I expect things would be pretty close.

However, for me that's a hard set of behaviors to stick to. If I let myself say, "Oh, I'll test that later" I'm likely to get lost in the problem, write bunch of production code, and then say, "Well, it already works, but I guess I'll add some tests." There's no clear stopping point.

Test-first programming, on the other hand, is easier for me to stick to. If I don't have a broken test, I write one. If I have made the test pass, it's time to write another test before I write more production code.

[ Parent | on HN ]