4 ms·

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 "

by tpmx 7y ago

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 7y ago
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.

by tpmx 7y ago

PaulHoule 7y ago

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.