Hacker News Reader

It's worth noting that Kent Beck ("Father of TDD") himself said that TDD doesn't always make sense. For him, the important thing has always been having a tight feedback loop for determining if he was still on the right track.

For instance, when he was working on an unstructured log parser, there was no way TDD would work because the logging stream didn't have a pre-defined structure. Instead, he developed a process where he could quickly inject his parser into the logging stream, visually inspect the results, tweak, and then test again.

Others (Such as Martin Fowler and Uncle Bob) have also emphasized the value of automated unit testing integrated with a CI pipeline as a way of ensuring that you didn't break existing functionality.

As always, what's important is not the specific practice, but rather the engineering principles behind it. The key questions being:

* Am I on the right track?

* Did I break existing functionality?

* How quickly and frequently can I get answers to the above two questions?

View on HN

* My personal TDD process are: * Script enable - always run every night, every weekends. Output to html files to see overall green/red in < 1 second. * When any existing test broke, fix/debug the tests are the highest priority before any more features development. * The test reports from all the nightly and weekend test should always be green. * Any red(s) will stop all features dev. * There are 5 minutes function test scripts that require to run before every commit. * Normally, I prefer commit in the morning after overnight test runs were all green. * These were small project with team only 1-2 devs. * Much easier to enforce the process. (Just need to convince I, me and myself.) * I worked on big team projects with 100+ devs. * I can test only my own part of code. For any big team, I can take the horses to the water but can't make anyone to drink it. The overall system SW quality was still bad. * I Only do full functional tests - I don't do any small unit tests with mocks. * For CDRW drive, there were 100+ test cases for close, read, open, repeat, close, read, write, loop, open, repeat, for different CD format, disk, drive, etc * For DNA sequencer machines, there were tests for Motor controls, 3 axis robot, CCD camera, laser control, script subsystem, comm sub sys, etc. (This is old project, 20+ yrs ago) Deployed in the field for 15+ years with version 1.0 Firmware. Good for company bottom line - not sure for the SW guy's career. :-) (Multi billions $$$ of revenue for the company, $500+M first year) * For video decoder systems with 19FPGA + 10G network: (10+ years ago) Streaming control, snmp, IGMP, all each has their own test scripts and combine system level scripts for complex network, HA setup. Deployed in Comcast for long time without any issue. Only one issue reported was system has problem after 255 days of non-stop running. I did have test case for 10 ms counters (for SW bug happened for 25, 49 days) I didn't create test case 100ms counters (for SW bug happened after 255 days). Again, very good for company bottom line. (Tens millions $$ of revenue for the startup) But the company don't need me anymore after they shipped that product.