5 ms·

TDD always worked for me. All successful projects in my career had full functional regression test coverage. For those successful projects, I made following

by srcmap 9y ago

TDD always worked for me. All successful projects in my career had full functional regression test coverage. For those successful projects, I made following conclusions: * 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.

lliamander 9y ago
Sounds like you're doing the right thing. Note that not every one would agree that you are doing "true TDD" (due to your lack of "unit" tests) but that doesn't matter. What matters is that: a) you are disciplined in your commitment to quality b) you offload as much of the tedious, repetitive work to the computer as possible. Regarding unit tests and mocking, I have a similar opinion. I tend to test at the larger component/package level rather than the smaller class/module level. Furthermore, I avoid mocking as much as possible. Object-Oriented decoupling through dependency injection makes mocking a lot easier (and removes the need for mocking frameworks) and Functional decoupling[0] makes mocking largely unnecessary. [0]http://prog21.dadgum.com/131.html http://prog21.dadgum.com/131.html
- charlieflowers 9y ago
  Along the same lines, checkout "Functional Core, Imperative Shell".
- crdoconnor 9y ago
  >Note that not every one would agree that you are doing "true TDD" (due to your lack of "unit" tests) I think he's doing it right in spite of what other religious zealots may say. In my experience, unit test driven development causes three massive problems: * Unit tests are intrinsically tight coupling. * Unit tests require you to build a model for most things that you are testing against (e.g. your database). Building these elaborate models (i.e. using mocks) is prohibitively expensive when you have tightly coupled code but they're often still expensive to build (in terms of developer time) even when you have loosely coupled code. * Unit tests are intrinsically unrealistic because they are built against models rather than the real thing. In my experience unit tests work adequately for domains that are heavy on complex logic and light on integration (e.g. writing a parser). In domains which are light on complex logic and heavy on integration they fail badly (e.g. most business apps). Optimizing for the overall speed of your test suite by using a more unrealistic test that catches fewer bugs is a massive false economy. CPU time is dirt cheap. QA and dev time is very expensive.
  - lliamander 9y ago

by srcmap 9y ago

lliamander 9y ago

Sounds like you're doing the right thing. Note that not every one would agree that you are doing "true TDD" (due to your lack of "unit" tests) but that doesn't matter. What matters is that: a) you are disciplined in your commitment to quality b) you offload as much of the tedious, repetitive work to the computer as possible. Regarding unit tests and mocking, I have a similar opinion. I tend to test at the larger component/package level rather than the smaller class/module level. Furthermore, I avoid mocking as much as possible. Object-Oriented decoupling through dependency injection makes mocking a lot easier (and removes the need for mocking frameworks) and Functional decoupling[0] makes mocking largely unnecessary. [0]http://prog21.dadgum.com/131.html http://prog21.dadgum.com/131.html

charlieflowers 9y ago
Along the same lines, checkout "Functional Core, Imperative Shell".
crdoconnor 9y ago
>Note that not every one would agree that you are doing "true TDD" (due to your lack of "unit" tests) I think he's doing it right in spite of what other religious zealots may say. In my experience, unit test driven development causes three massive problems: * Unit tests are intrinsically tight coupling. * Unit tests require you to build a model for most things that you are testing against (e.g. your database). Building these elaborate models (i.e. using mocks) is prohibitively expensive when you have tightly coupled code but they're often still expensive to build (in terms of developer time) even when you have loosely coupled code. * Unit tests are intrinsically unrealistic because they are built against models rather than the real thing. In my experience unit tests work adequately for domains that are heavy on complex logic and light on integration (e.g. writing a parser). In domains which are light on complex logic and heavy on integration they fail badly (e.g. most business apps). Optimizing for the overall speed of your test suite by using a more unrealistic test that catches fewer bugs is a massive false economy. CPU time is dirt cheap. QA and dev time is very expensive.
- lliamander 9y ago