7 ms·

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

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?

YZF 9y ago
I absolutely agree. It's also nice to know: * What's my confidence that the code will work correctly under different situations. * How maintainable the code is and related how easy is it to make changes. * How much time/effort does it take to create. It's funny (or sad) how the XP guys like Kent are always talking about doing the right thing and not being religious. This stops working when the people using it don't know what the right thing is any more. They write terrible tests, they make bad changes to their code to support those tests, it ends up a big un-refactor-able ball of mud that takes longer to create and is more difficult to maintain. If you're writing a shortest path algorithm or a JPEG decoder then you absolutely should code up some tests to check your code. The tests are relatively simple. They don't need to know anything about the internals of your code. They help you check quickly whether your code is correct and don't interfere with any refactoring. You can rewrite your JPEG decoder from scratch without needing to touch the tests at all.
- convolvatron 9y ago
  i'm not a fan of tdd, and a huge proponent of testing in general. what you say about making bad changes to support tests really strikes a chord. in tdd environments the test harness is used as some kind of crutch to avoid having to have difficult discussions about what the product should* be doing - what makes sense. the test acts as some kind of oracle in the regard, even though it was written by an intern last spring who didn't really have any idea what was supposed to happen either. i'm basically afraid to say 'the test is wrong' anymore. i always get back a blank look of incomprehension or even outright fear.
  - mvindahl 9y ago
    Word. I have also worked on projects where existing tests were treated like holy cows. Deleting a test wasn't disallowed as such but it really required a convincing justification. Ironically, this made it especially hard to touch the inevitable subset of tests which had grown unreadable and which were not tracable to specs. Hence, they were often left alone, smelling riper with each passing year. I like to think of production code as being inherently a liability, not an asset, and the same goes for test code. That's not to say that code, or tests, cannot be valuable; it's just that every line of code carries a cost to the business just by adding complexity to the development process and by taking up disk space and CPU cycles. Not all code offsets this cost, and a lot of tests certainly don't. We should stop viewing tests like holy scriptures. Some add long term value, some add value during initial development, some should never have been written in the first place. And on a side note, our tests should test the business requirements, i.e. they should be tracable to specs. There are a lot of tests out there which amount to little more than to "test" some arbitrary decisions which we made when someone initially fleshed out a class diagram.
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
polm23 9y ago
Do you have a link to when Kent Beck was working on that log parser?
- lliamander 9y ago
  The "Is TDD Dead"[0] discussion between Martin Fowler, Kent Beck, and DHH. [0]https://martinfowler.com/articles/is-tdd-dead/ https://martinfowler.com/articles/is-tdd-dead/

YZF 9y ago

I absolutely agree. It's also nice to know: * What's my confidence that the code will work correctly under different situations. * How maintainable the code is and related how easy is it to make changes. * How much time/effort does it take to create. It's funny (or sad) how the XP guys like Kent are always talking about doing the right thing and not being religious. This stops working when the people using it don't know what the right thing is any more. They write terrible tests, they make bad changes to their code to support those tests, it ends up a big un-refactor-able ball of mud that takes longer to create and is more difficult to maintain. If you're writing a shortest path algorithm or a JPEG decoder then you absolutely should code up some tests to check your code. The tests are relatively simple. They don't need to know anything about the internals of your code. They help you check quickly whether your code is correct and don't interfere with any refactoring. You can rewrite your JPEG decoder from scratch without needing to touch the tests at all.

convolvatron 9y ago
i'm not a fan of tdd, and a huge proponent of testing in general. what you say about making bad changes to support tests really strikes a chord. in tdd environments the test harness is used as some kind of crutch to avoid having to have difficult discussions about what the product should* be doing - what makes sense. the test acts as some kind of oracle in the regard, even though it was written by an intern last spring who didn't really have any idea what was supposed to happen either. i'm basically afraid to say 'the test is wrong' anymore. i always get back a blank look of incomprehension or even outright fear.
- mvindahl 9y ago
  Word. I have also worked on projects where existing tests were treated like holy cows. Deleting a test wasn't disallowed as such but it really required a convincing justification. Ironically, this made it especially hard to touch the inevitable subset of tests which had grown unreadable and which were not tracable to specs. Hence, they were often left alone, smelling riper with each passing year. I like to think of production code as being inherently a liability, not an asset, and the same goes for test code. That's not to say that code, or tests, cannot be valuable; it's just that every line of code carries a cost to the business just by adding complexity to the development process and by taking up disk space and CPU cycles. Not all code offsets this cost, and a lot of tests certainly don't. We should stop viewing tests like holy scriptures. Some add long term value, some add value during initial development, some should never have been written in the first place. And on a side note, our tests should test the business requirements, i.e. they should be tracable to specs. There are a lot of tests out there which amount to little more than to "test" some arbitrary decisions which we made when someone initially fleshed out a class diagram.

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

polm23 9y ago

Do you have a link to when Kent Beck was working on that log parser?

lliamander 9y ago
The "Is TDD Dead"[0] discussion between Martin Fowler, Kent Beck, and DHH. [0]https://martinfowler.com/articles/is-tdd-dead/ https://martinfowler.com/articles/is-tdd-dead/