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.
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.
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.
3 comments
[ 0.22 ms ] story [ 20.5 ms ] threadTesting 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.
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.
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.