4 ms·

This article is just irritating sarcasm. There are perfectly good reasons to avoid test-driven development. Like being part of an existing large project, where

This article is just irritating sarcasm. There are perfectly good reasons to avoid test-driven development. Like being part of an existing large project, where there are already too many interconnected components. Or working in complex AI algorithms, where separate testing of components is extremely painful, and lots of whole system testing is necessary anyway.

deleted 14y ago
[deleted]
benjaminwootton 14y ago
Could you expand on this? Why are too many interconnected components or a complex AI algorithm a valid reason not to test or use test driven development? My view is that in a complex system, only by having confidence in the units can you have confidence in the integrated whole. You might be able to build a house that stands and looks nice, but if the timbers, the bricks, the foundations etc are all flawed in their own small ways, sooner or later those problems are going to combine and you will end up squashed. I can't think of a single example where automated testing couldn't potentially improve what you deliver and the process of working on it. Even the hackiest throwaway script could likely be produced faster and easier with a little automated driver.
- plinkplonk 14y ago
  "I can't think of a single example where automated testing couldn't potentially improve what you deliver and the process of working on it. Not engaging with the above argument, just trying to clarify an ambiguity. Just saying (and trying hard to keep tone neutral). automated testing != test driven development. The former has been in use for decades. The latter is a relatively new methodology/practice which emphasizes writing tests first and using tests to drive development.
- CJefferson 14y ago
  Oh, we certainly do massive automated testing. Our release testing script takes currently an 8-core machine about 4 days, and our nightly test runs on about 6 configurations, taking about 2 hours. However, often the units have properties which are very difficult to specify in isolation, and from experience almost all bugs come from many algorithms reading and writing the same data structure (I'm not thinking of threading issues here, although they are another issue). Consider something like a sudoku solver (the things I work on are much more complicated than that). Usually writing the function which checks the condition 'a row/column/box are all different' is very simple. The errors come when these functions interact, each effecting each other as they are called. Certainly, this kind of situation is very unusual. Most people write code which lends itself more naturally to test-driven development, and in those situations I approve of it.
lucisferre 14y ago
Agreed this was completely pointless. Bottom line is not every line of code needs testing, and TDD alone does not have an impact on code quality. There is nothing I hate more than bad code covered by even worse test code. Here is a talk for anyone who is wondering why TDD doesn't make sense as a default mode: http://www.youtube.com/watch?v=LeVvj4HENOQ http://www.youtube.com/watch?v=LeVvj4HENOQ Bottom line is that writing TDD style unit tests won't make crap code better any more than removing them makes good code worse. TDD is a tool, nothing more, nothing less.
- rhizome 14y ago
  Hmm...a 90min Youtube will have to wait until I'm done writing tests.
- tzaman 14y ago
  Not entirely true: If you write tests, chances are you're educating yourself on how to write them. As a consequence, code gets improved - because it's almost impossible to write any kind of tests if the code is crappy. But then again, maybe that's just me :)
  - lucisferre 14y ago
    You and I probably feel that way, but I've seen many people who will beat their heads against that wall and write bad tests for bad code. As for the educating yourself part, yes you'll become a better dev if you are just starting out writing tests. But at some point you'll either become less dependent on them or dogmatic about them. I prefer the former.
  - dasil003 14y ago
    I think it is entirely true: > TDD is a tool, nothing more, nothing less Essentially TDD is just one more form of testing and/or specification. The reason it's so good is because of the properties of executable code: namely that it's fast, precise and repeatable. Human-based QA processes also have their advantages, and if you had unlimited human QA resources then the value of automated testing would be significantly (though not entirely) diminished. But in the end, testability is ancillary, it's a second-order concern to the actual operation of the software. The ability to write a good test is secondary to the ability (and wisdom!) to choose the right architecture. In other words, a simple and correct program using some advanced techniques in, let's say Haskell, would be preferable to a kludgy Frankenstein beast of a program written in Ruby but with great test coverage over the areas of the problem domain that the programmer was aware of. Obviously that's a straw man; automated testing is an extremely powerful technique, one which requires practice to master, and TDD shines in its ability to lift the scales from the eyes of the beginning programmer and see programming from a new perspective. However TDD, BDD et al are no silver bullet and no different from learning functional progamming, gdb, printlining, modular programming, meta programming, dynamic programming, regular expressions, or any other algorithm or technique. All just tools.
__david__ 14y ago
Also, code that controls hardware is very hard to test. Consider writing tests for the the Linux kernel's device drivers. It would be very difficult because most of the problems have to do with hardware being buggy/underspecified, not with the software being wrong in a testable way. In order to test a UART driver you have to to simulate the way the UART worked, which means that you wouldn't catch bugs if your understanding of the hardware was wrong. Most of the time spent would be recreating the internal logic of the UART and it wouldn't actually benefit you unless you got it right. The other option to test the UART is to have a rig set up that where you can run the code on the device and have the serial port looped back or go into another computer that checks the result. But that (by definition) means special hardware is required to run that test, which makes it way less useful as an automated test. Neither of those situations is amenable to TDD.
- mpweiher 14y ago
  There's actually a fairly simple way to deal with external systems that to me would seem to apply to hardware as well: First, write code that "tests" the actual hardware, that means it drives the hardware and checks its results. Verify using whatever means you have available that it drives the hardware correctly. Second, create a variant of this first test (class) that runs against your simulator (checking for the same results). I used a trivial subclass that changed nothing except replacing the device interface with the simulator. Third, write your simulator against these tests. Fourth, use your simulator to test the remainder of your system without requiring the hardware/external system. Extend when you make use of new features, and occasionally test against the real system/hardware...
codewright 14y ago
The tl;dr (it's a software product I think?) for this article is a dead-pan recitation and is hilarious.
lancefisher 14y ago
I thought it was going to be sarcasm, but clicked through anyway hoping it wasn't. Sarcasm is annoying and often hurtful. I've tried to eliminate it from my everyday speech. Maybe that's a reason this article irks me, and I like TDD.

deleted 14y ago

[deleted]

benjaminwootton 14y ago

Could you expand on this? Why are too many interconnected components or a complex AI algorithm a valid reason not to test or use test driven development? My view is that in a complex system, only by having confidence in the units can you have confidence in the integrated whole. You might be able to build a house that stands and looks nice, but if the timbers, the bricks, the foundations etc are all flawed in their own small ways, sooner or later those problems are going to combine and you will end up squashed. I can't think of a single example where automated testing couldn't potentially improve what you deliver and the process of working on it. Even the hackiest throwaway script could likely be produced faster and easier with a little automated driver.

plinkplonk 14y ago
"I can't think of a single example where automated testing couldn't potentially improve what you deliver and the process of working on it. Not engaging with the above argument, just trying to clarify an ambiguity. Just saying (and trying hard to keep tone neutral). automated testing != test driven development. The former has been in use for decades. The latter is a relatively new methodology/practice which emphasizes writing tests first and using tests to drive development.
CJefferson 14y ago
Oh, we certainly do massive automated testing. Our release testing script takes currently an 8-core machine about 4 days, and our nightly test runs on about 6 configurations, taking about 2 hours. However, often the units have properties which are very difficult to specify in isolation, and from experience almost all bugs come from many algorithms reading and writing the same data structure (I'm not thinking of threading issues here, although they are another issue). Consider something like a sudoku solver (the things I work on are much more complicated than that). Usually writing the function which checks the condition 'a row/column/box are all different' is very simple. The errors come when these functions interact, each effecting each other as they are called. Certainly, this kind of situation is very unusual. Most people write code which lends itself more naturally to test-driven development, and in those situations I approve of it.

lucisferre 14y ago

Agreed this was completely pointless. Bottom line is not every line of code needs testing, and TDD alone does not have an impact on code quality. There is nothing I hate more than bad code covered by even worse test code. Here is a talk for anyone who is wondering why TDD doesn't make sense as a default mode: http://www.youtube.com/watch?v=LeVvj4HENOQ http://www.youtube.com/watch?v=LeVvj4HENOQ Bottom line is that writing TDD style unit tests won't make crap code better any more than removing them makes good code worse. TDD is a tool, nothing more, nothing less.

rhizome 14y ago
Hmm...a 90min Youtube will have to wait until I'm done writing tests.
tzaman 14y ago
Not entirely true: If you write tests, chances are you're educating yourself on how to write them. As a consequence, code gets improved - because it's almost impossible to write any kind of tests if the code is crappy. But then again, maybe that's just me :)
- lucisferre 14y ago
  You and I probably feel that way, but I've seen many people who will beat their heads against that wall and write bad tests for bad code. As for the educating yourself part, yes you'll become a better dev if you are just starting out writing tests. But at some point you'll either become less dependent on them or dogmatic about them. I prefer the former.
- dasil003 14y ago
  I think it is entirely true: > TDD is a tool, nothing more, nothing less Essentially TDD is just one more form of testing and/or specification. The reason it's so good is because of the properties of executable code: namely that it's fast, precise and repeatable. Human-based QA processes also have their advantages, and if you had unlimited human QA resources then the value of automated testing would be significantly (though not entirely) diminished. But in the end, testability is ancillary, it's a second-order concern to the actual operation of the software. The ability to write a good test is secondary to the ability (and wisdom!) to choose the right architecture. In other words, a simple and correct program using some advanced techniques in, let's say Haskell, would be preferable to a kludgy Frankenstein beast of a program written in Ruby but with great test coverage over the areas of the problem domain that the programmer was aware of. Obviously that's a straw man; automated testing is an extremely powerful technique, one which requires practice to master, and TDD shines in its ability to lift the scales from the eyes of the beginning programmer and see programming from a new perspective. However TDD, BDD et al are no silver bullet and no different from learning functional progamming, gdb, printlining, modular programming, meta programming, dynamic programming, regular expressions, or any other algorithm or technique. All just tools.

__david__ 14y ago

Also, code that controls hardware is very hard to test. Consider writing tests for the the Linux kernel's device drivers. It would be very difficult because most of the problems have to do with hardware being buggy/underspecified, not with the software being wrong in a testable way. In order to test a UART driver you have to to simulate the way the UART worked, which means that you wouldn't catch bugs if your understanding of the hardware was wrong. Most of the time spent would be recreating the internal logic of the UART and it wouldn't actually benefit you unless you got it right. The other option to test the UART is to have a rig set up that where you can run the code on the device and have the serial port looped back or go into another computer that checks the result. But that (by definition) means special hardware is required to run that test, which makes it way less useful as an automated test. Neither of those situations is amenable to TDD.

mpweiher 14y ago
There's actually a fairly simple way to deal with external systems that to me would seem to apply to hardware as well: First, write code that "tests" the actual hardware, that means it drives the hardware and checks its results. Verify using whatever means you have available that it drives the hardware correctly. Second, create a variant of this first test (class) that runs against your simulator (checking for the same results). I used a trivial subclass that changed nothing except replacing the device interface with the simulator. Third, write your simulator against these tests. Fourth, use your simulator to test the remainder of your system without requiring the hardware/external system. Extend when you make use of new features, and occasionally test against the real system/hardware...

codewright 14y ago

The tl;dr (it's a software product I think?) for this article is a dead-pan recitation and is hilarious.

lancefisher 14y ago

I thought it was going to be sarcasm, but clicked through anyway hoping it wasn't. Sarcasm is annoying and often hurtful. I've tried to eliminate it from my everyday speech. Maybe that's a reason this article irks me, and I like TDD.