Head of Product at Temporal. Previously lead architect and low-level systems programmer for scale out SaaS offering. Game engine developer, ML engineering expert. DMs open on Twitter.
While I didn't get a chance to check out all the TDD articles referred in the summary article, from spot checking a few it's my feeling that these huge percentage increases in reliability come from comparisons with projects without any tests at all.
Obviously there are many studies listed in this table (along with another table of academic studies I've omitted). I think it's obvious that many of these companies were testing before switching TDD (such as IBM).
It really is never explained why writing the tests first is advantageous over writing them while you write the code. What I find particularly in real-world code is that 80% of it requires very basic testing, but about 10% requires extremely intensive testing to cover a lot of edge cases - and it really isn't obvious which that 10% is going to be before you actually run into the real issues.
It's both explained in my post and in the sources I link. This article by Eric Elliot should cover most of your questions. The TLDR is that TDD provides similar benefits to code reviews and generally forces your code to be more communicative and functional. I might skip TDD if I'm using a language like Typescript which makes it incredibly easy to define all my interfaces/API's before I actually start coding.
Another disadvantage is in spike development. In the earliest stages of a module, I might have four or five different approaches that I play with in different branches. In this phase, I write very few tests if any, because I throw away all but one of the approaches before going on.
As I said in my post, take everything with a grain of salt. If you're in the "exploration" phase you probably don't need to be as rigid with your standards. Once you start working on a "feature", I would personally recommend writing tests.
I've been in all parts of the industry for decades, in companies that do very heavy testing, and yet I haven't been in one shop that does TDD - i.e. writes the tests first.
It's a mixed bag. It takes a lot of discipline to correctly practice TDD and discipline does not scale. I know quite a few engineers at top notch companies (Google, Snapchat etc) who are absolutely TDDers (is that a thing?). But I'm talking about purist TDD here, not writing unit tests as you code. With a broader definition I know countless companies that fall into the categorization.
Thanks for the great comment and creating a wonderful discussion around TDD!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
From the source linked in my post
Obviously there are many studies listed in this table (along with another table of academic studies I've omitted). I think it's obvious that many of these companies were testing before switching TDD (such as IBM).
It's both explained in my post and in the sources I link. This article by Eric Elliot should cover most of your questions. The TLDR is that TDD provides similar benefits to code reviews and generally forces your code to be more communicative and functional. I might skip TDD if I'm using a language like Typescript which makes it incredibly easy to define all my interfaces/API's before I actually start coding.
As I said in my post, take everything with a grain of salt. If you're in the "exploration" phase you probably don't need to be as rigid with your standards. Once you start working on a "feature", I would personally recommend writing tests.
It's a mixed bag. It takes a lot of discipline to correctly practice TDD and discipline does not scale. I know quite a few engineers at top notch companies (Google, Snapchat etc) who are absolutely TDDers (is that a thing?). But I'm talking about purist TDD here, not writing unit tests as you code. With a broader definition I know countless companies that fall into the categorization.
Thanks for the great comment and creating a wonderful discussion around TDD!