Ask HN: What's Your Stance on TDD? - mdgrech23
======
__s
Read Chapter 20 of Code Complete

Testing is one part of QA. It's good to have it from the start. But in the end
you need multiple dimensions of QA as each find non overlapping sets of issues

Most importantly: experiment. Find what works for your team on your product.
Maybe TDD works. Maybe it works to brainstorm tests during the review stage

Code Complete does push that the earlier you detect an issue the cheaper it is
to fix. TDD certainly makes a noble effort to detect issues early

& to quote Chapter 22: All in all, I think test-first programming is one of
the most beneficial software practices to emerge during the past decade and is
a good general approach. But it isn't a testing panacea, because it's subject
to the general limitations of developer testing, which are described next.

------
tpmx
Done in light moderation it's useful, especially in fields that really lean
themselves towards this (stuff like e.g. compilers). We used to just call that
the "test suite" back in the 90s before TDD was a thing.

It's a common mistake for TDD-addicted newbies to drag down their own
productivity by spending half of their time writing mostly pointless test
cases, even when they're just writing exploratory code, or code that doesn't
really lend it self to be self-tested.

~~~
PaulHoule
Anything involving string handling or parsing is good to do with TDD. It is so
easy to get those things wrong, security is a concern, and some day you'll
find your parsing code is frustratingly slow and have to rework it.

In some cases the real uncertainties are in the behavior of the environment.
(e.g. back in Java 1.1 when AWT components had an 'invalidate' method that was
documented to 'invalidate the component') Some GUI frameworks lend themselves
to testing (a Vue application contains many pure functions that can be tested
alone), others make it hard.

Testing comes in different levels too. Sometimes automated integration tests
are better than unit tests, even if they take longer to run. (Like that time I
wrote a micro-ORM for one version of mysql, and took about two hours to port
it to the next version of mysql and to MS SQL since I had tests)

Sometimes testing out the core of a multithreaded app for 300 seconds with 200
threads is a good way to know that if race conditions are there they are very
rare. On the other hand you just can't run a test like that on every build.

I often write test suites for the standard library when I don't understand
what it does. For instance, I got a good understanding of how asyncio works in
Python by writing test cases that use coroutines in unusual ways, which helps
me write coroutine-based frameworks.

