
A Longitudinal Cohort Study on the Retainment of Test-Driven Development - ingve
https://arxiv.org/abs/1807.02971
======
gmiller123456
While I'm no advocate of TDD, I think they trivialized the arguments for it.
They just measured "productivity" (number of tasks completed) and "quality"
(number of tests that passed). The primary argument I've heard for TDD is
modifying an existing system. You have a lot of tests that all successfully
pass, so you can modify the system without fear of breaking it without knowing
you did. Another reason is that the system becomes self documenting, making it
easier to understand for people in the future. This study didn't really
attempt to tackle those.

Also, the tasks the programmers were assigned were tested for "quality" and
completeness automatically. So it makes me think the tasks were of the type
that favor being tested automatically, and thus biased towards benefiting from
TDD.

------
JoeAltmaier
Um, it had no effect on quality nor productivity. Yet they _still_ recommend
it? What koolaid have they drunk?

~~~
iamleppert
People who write bad code also write bad tests. People who write good code
write good tests, but you can argue that their code quality would be more or
less the same without the tests.

A far better use of time is to write better code and spend time improving the
actual code along with human readable documentation about what said code is
doing. I've removed and reduced 1000's of lines of code and their accompanying
technical debt (tests) to reduce the system down into a manageable and fully
readable system that is far superior to the old system with the exhaustive
test suite and spent the rest of the time writing documentation on how the
code works.

~~~
RandallBrown
How did you know that the code still worked after you refactored it?

At the very least, the tests are a list of things the code should do.

~~~
jazoom
Try it and see if it works?

~~~
posixplz
What could possibly go wrong?

If a refactor is sufficiently canonical that "try it" is acceptable, and you
have little/no edge cases, then it should be trivial to write a good test for
the same code. After all, what does a test do, besides "try it"?

------
Animats
_" We conducted a (quantitative) longitudinal cohort study with 30 third year
undergraduate students in Computer Science"_

No.

Not only is it a college student based study, how do you do a "longitudinal
study" in a short period of time?

------
megaman22
Test-driven development never made a lot of sense to me. But I write code that
deals with messy, poorly documented external real-time services that cannot be
mocked without an absurd amount of effort. I try to pull out the bits of more
pure code that I can and get that under test, but trying to go much further
than that is counterproductive.

