Fork me on GitHub

Nice. There is so much bad research, and tenuous research, in the world.


Also there is a problem with overloading the term TDD. Do you mean “TDD” as code for “write unit-level tests for every branch of code, but it’s OK to write them after the code, as long as it’s shortly after”? Or do you mean “TDD” as “you must write a failing test before you can write anything”? In my opinion the latter is a great training exercise, but very rarely actually done, and often impractical.


Though there’s ATDD where you write a failing high-level test first - but I don’t think that’s what people think when they talk about TDD.


So, in this case, if they are comparing “TDD” with “Iterative Test-Last Development” - i.e. a strict definition of TDD, versus people still writing unit-level tests for their code, but afterwards. I’m not sure this is what most people, especially most managers, will deduce from the title - they’ll say “well, that TDD thing has been proven not to work” 😞


@otfrom I also think anything like this study has huge methodological problems. Basically, if you have good people who know what they're doing and share a vision of the architecture and what 'good' looks like your methodology is irrelevant. The tools they use may be TDD (which I like personally as I can't test last without being heavily influenced by the implementation which dilutes the usefulness of my tests and tends to make them more 'white box' and brittle). they could equally be something else. However, IMO (and it's a very subjective opinion), regardless of whether it's a test first approach (like TDD) or ITL, you should codify your design in tests for the following reasons: 1. Regression - to detect breaking changes 2. A guide to completeness of requirements (it's never 100%) 3. A way of 'sensing' and documenting behaviour of your code 4. Communicating design decisions in the form of tests as examples (which is why I would always have some example based tests as I personally find generative tests that codify invariant properties hard to grok at a glance)


I would add one more 28 years I've never worked anywhere that used ITL that had tests that did any of the four points above to any degree. Most had <5% test coverage. This is human nature as the pressures to deliver mean tests are the first things to go. That more than any other reason is why I like 'test first', preferably A-TDD as well as TDD at 'unit' level.


With reagrd to point 4 - at my current client tests are not prolific but where there are some I've found it much, much faster to understand what the code does and how to change it. This usually goes: 1. Read and run existing tests 2. Talk about what needs to change and what inputs give what outputs in the form of test scenarios 3. Write test for a small change (that fails)


4. Implement and refactor using tests to ensure nothing else breaks


This process has already stopped me introducing a bunch of bugs into the codebase


I use TDD as another feedback loop just like the REPL


> 1. Regression - to detect breaking changes


this for me is the main main main thing


being able to refactor and experiment with design without fear is what keeps development fast


I’m using TDD this morning to incrementally add new functionality without regressing existing stuff, if I was doing ITL, i’m not sure how else i’d check that the new thing does what I expect


except something like having an example that should work in the REPL, which seems pretty much the same thing


@glenjamin exactly what I'm doing in my current work


I am adding a test for the new example (that fails) and then implementing it (which I know I've done when tests for new functionality pass). I always think of other tests once I've implemented so I usually add them as I go along.