11 ms·

Giving Up on TDD

131 points by mxhold 11y ago

legulere 11y ago
> but he said he was just using it for some home projects I think here lies the biggest problem. For small/hackish projects you barely get any benefits from test driven development but still have the higher costs. Test-driven development means that you will spend more effort while developing, but will have to spend less on maintaining in the long run. The fun part about home projects is that you don't really have to think about maintenance at all and you can just hack things away until they work for you. PS: you should write out acronyms once in the beginning of an article
- LordDragonfang 11y ago
  I spent the majority of the article thinking it stood for the "top-down design" that my intro to programming professor was so fond of.
- EdSharkey 11y ago
  My home projects become tragic when they get past the trival size and I haven't been TDD'ing and designing all the way through. I think part of my problem is that I cannot devote a consistent level of effort every week to my current home project. Sometimes I'll leave and when I come back to it, I'm lost without a test suite and wind up rewriting huge swaths of it. Really good tests also serve as up-to-date documentation of your design. If you code in Java or Groovy, check out the Spock Framework. Spock tests read like a story. I wish there was a Spock-like DSL for JavaScript development.
  - vorg 11y ago
    Spock hacks into Groovy's AST to make labelled expressions have special meanings: def "adder-test"() { given: "a new Adder class is created" def adder = new Adder(); expect: "Adding two numbers to return the sum" adder.add(3, 4) == 7 } It could all easily break if the Groovy parser or AST is updated. And very clunky, which says something about Groovy's design post v 1.5.
robert_tweed 11y ago
Title is slightly misleading, so for anyone reading the comments first, this is Uncle Bob's rebuttal of yesterday's "Giving up on test-first development", in the form of a Q&A. Original discussion here: https://news.ycombinator.com/item?id=11310711 https://news.ycombinator.com/item?id=11310711
me_again 11y ago
Q: Are you sick of the Socratic method? A: Oh God yes. Q: What's wrong with it? A: It's overly verbose, condescending, and allows you to give the appearance of resolving a debate when all you've actually done is talk down to a sock puppet.
- ktRolster 11y ago
  Q: Why should that be different than any other type of rhetoric? A: If you want truth, read a scientific study, not a blog.
  - dave2000 11y ago
    Q. Are there actually proper studies done by and of proper developers writing proper (ie not trivial crap) code which demonstrate the pros and cons of TDD?
    - ktRolster 11y ago
      A. This one is probably good, it compares actual software teams: http://www.infoq.com/news/2009/03/TDD-Improves-Quality http://www.infoq.com/news/2009/03/TDD-Improves-Quality It shows in increase in quality, but with an increase in development time. It is my un-studied assessment that the improvements seen from TDD are primarily a result of the programmers thinking more. It pushes you to think of every edge case. It also gives more experienced programmers a chance to mentor younger programmers (for example, you can easily look at the test coverage and say, "look, you need to test these things too." It's harder to do that (though still possible) without tests).
- greenyoda 11y ago
  "It's overly verbose, condescending, and allows you to give the appearance of resolving a debate when all you've actually done is talk down to a sock puppet." I agree with your criticism of the article's style. But to be fair, if you're arguing with yourself (as the author is), it's not really the Socratic Method, which is a dialog with another person. If you don't get to control what questions the other person asks, it makes for much a more interesting conversation.
jblow 11y ago
For many paragraphs, I thought this was a parody of TDD defense, but then it turns out it wasn't. His 'defense' of the point is basically: Look, when you do TDD you have to put a lot more work into the tests than you thought! It is not just a simple thing! Okay, fine, but ... Before embarking on TDD, the programmer had a picture in his head of what the costs+benefits of this change would be. Now you are telling him the costs are WAY higher. So a successful defense would have to then make the case that the benefits are also WAY higher. But he doesn't. Because the benefits aren't higher, in fact they are lower (as is the case with every well-intended scheme in the history of anything.) As usual my advice on this is: look at the people who build things you find highly impressive, and study how they did it. This is much more fruitful than reading the output of people who want to spend all day telling you how to program (which leaves very little time for them to build software that is impressive, i.e. they never even test their own ideas!)
- howareroark 11y ago
  I like your usual advice! I imagine there are a lot of very ingenious things hidden within the code of people who have never written an article. Or even just contradictions to articles that they may have written. I find a lot of articles tend to just build upon common assumptions with a unique twist. Makes sense though, people want to read things that validate their assumptions. People want to write things that people want to read.
- aalvarado 11y ago
  TDD is better than no tests most of the time I think. So at least that's a gain altogether.
  - aalvarado 11y ago
    I do TDD rarely, I like it when I'm on pristine projects, I feel it works when working alone on code you're outside your paying job. Or a library that you don't need to do much exploration programming. I add tests after the fact for most of my programming, usually because that's how I feel more comfortable. Sometimes it is a net win to figure out how something works by experimenting with different ideas and start having a feel of the software you're creating. Without slowing down for trying to think about correctness every time you write something down. TDD should not be, "An always on" kind of thing, I feel like most of what software has taught me is "Use where better suited" which this I think is the main reason why I feel I differ with his view which I think it is, use always. I kind of think that people with those bracelets about "always doing TDD" are thinking.
ryanbrunner 11y ago
There's definitely some good points here, but I have a huge issue with this point: > Something that is hard to test is badly designed. In my experience, TDD has a natural tendency to favour decoupling at all costs, and TDD zealots will push de-coupling units as an unqualified positive. And if your metric is "good design = easily testable and low coupling" it certainly looks that way. This mindset fails to take into consideration the fact that tightly coupled things are often simpler to understand and reason about. They're more closed to extension, sure, and harder to test in isolation, but a straightforward process that acts like a "black box" and performs a job simply in a few lines of code is often better than the class explosion that rigid TDD often encourages. And what's the value of keeping things open to extension if the only thing that is going to reasonably extend them are tests? A good illustration made by DHH as part of one of his anti-TDD tirades is here: https://gist.github.com/dhh/4849a20d2ba89b34b201 https://gist.github.com/dhh/4849a20d2ba89b34b201 Anyone who can honestly say the latter example has a better design has a very different opinion on "good design" than I do.
- ktRolster 11y ago
  His point, as phrased, is correct though, something that is hard to test is badly designed. You need to be able to test your software in some way or another. Even if you've proven its correctness, you still want to put it through some basic sanity tests (as Donald Knuth pointed out).
  - sago 11y ago
    Yes, but it misses the point of the criticism. The issue isn't whether the final product is difficult to test. It should be roughly as easy to test the final product no matter the implementation strategy. The problem is that TDD requires a royal-road of testing. No code can be written without tests for that specific piece of code. So you can only build the whole out of components that are testable in isolation. The claim is that this excludes architectures that don't provide such a step-by-step path of testing. This interacts badly with the 'make everything an API' idea. You end up with these functionally small units with over-engineered APIs rather than something more complex, more efficient, and easier to refactor as a whole.
exabrial 11y ago
Tdd is actual engineering: requirements first, set expectations, plan, estimate, build. Silicon Valley (generalization) has extreme shortsghtedness when it comes to building software, there are a lot of prima donnas, hipsters using whatever is cool,tech decisions made on opinion rather than measurement, and NIH. Have a spine and push for tdd. The prima donnas will attack you ad hominum and call you slow. But it feels pretty damned good to be right.
- mikegioia 11y ago
  The prima donnas will attack you ad hominum and call you slow. I don't know whether to laugh at or applaud the irony of that statement.
- stuartaxelowen 11y ago
  actual engineering prima donnas, hipsters have a spine And then... The prima donnas will attack you ad hominum I'm not for or against TDD, but you've gotta see the irony here.
- marcosdumay 11y ago
  > requirements first, set expectations, plan, estimate, build So, all the process that is known for decades to mostly not work for software?
- usrusr 11y ago
  That's why conservative engineering traditions mandate that whenever one sets out to design a bridge, the very first thing to do is to build a really heavy car.
  - overgard 11y ago
    You also want to make sure your heavy car falls off the leading edge of the bridge before you raise the support structure for that part. So you're sure you're not building unnecessary bridge parts.
facepalm 11y ago
And communism would work if only people would do it properly. It seems to me that kind of argument could be made about anything. "It only didn't work because you didn't do it properly". Doesn't it work for Homeopathy, too? "It would have worked if you hadn't passed it through the x-ray scanner at the airport" or "it would have worked if you had taken the medicine while doing a handstand". In the end doing it right becomes so complicated that you need to hire an expert to do it for you. Wonder if that was the point all along - basically marketing.
- Ace17 11y ago
  Some disciplines are hard to do properly, and easy to do wrong. It's a mistake to dismiss them just because the return on investment isn't immediate. We're mostly programmers here, we're not supposed to be afraid of steep learning curves!
  - facepalm 11y ago
    Sure, although my heuristic for trying new Software methodology tends to be "does it make things simpler?". That article made my head hurt...
- jacques_chester 11y ago
  The communism analogy is better than the homeopathy analogy. The former makes problematic assumptions about human nature, the latter impossible assumptions about physical reality. That said, I work in a company where TDD is the default. So far everything still works and there are no tanks rolling into any public squares to squash the bourgeois scourge.
barrkel 11y ago
This is an argument against a straw man, IMO; people who have a problem with TDD don't (or shouldn't) have a problem with testing, or creating a design that is testable. What TDD is specifically poor at is design. Test Driven Design literally means your tests drive the design of the system, rather than any other consideration, like reducing API scope, reducing complexity, reducing configurability (yes, excess configurability is a bad thing, and TDD tends to encourage it). TDD in particular won't drive insightful designs, because insight is a product of a fertile and well stocked mind meeting a problem domain - it does not emerge organically out of tests.
sago 11y ago
To me, TDD means: 1. No functionality is coded without a failing test. 2. Only code the minimum functionality to make the test pass. It does not mean 'test more' or 'write tests'. So I'm not sure more than 10% of this 'defence' bolsters the method at all. Seems like the normal rhetorical bait and switch - you pretend that your opponent is criticising testing and respond by defending some more or less vague notion of tests, with no substantive defence of TDD beyond "you didn't try hard enough." The example of the pacemaker, for example, has no relevance to TDD whatsoever.
- davidjnelson 11y ago
  Don't forget 3. Easily and safely refactor both your production and test code.
overgard 11y ago
Regardless of if TDD works, we see this argument pattern all the time, some magical claim for effectiveness is asserted via a methodology (always anecdotally), someone says "didn't work for me" and the response is ALWAYS "well you didn't do it long enough to get it!" It's all just noise. Theres nothing wrong with having your pet theory, I just wish entire industries wouldn't carelessly hop on board every time some consultant comes up with an acronym and some promises.
EdSharkey 11y ago
Forcing yourself to not write a line of production code without having a test in place to test it first produces a very high level of coverage over all your control paths. You wind up with the tests being an ad hoc specification for the production code. Not really a design as much as documenting the code. This is a really irksome way for me to work, and I find that level of diligence difficult to muster. Often I will find myself writing the production code first and writing tests to cover after the fact. My coverage is probably not as high as it is when I TDD the code. The cadence of TDD'd projects I've worked on professionally is painfully slow and predictable. If you're at a workplace that is giving you the time and resources to do it, then you're likely also pairing, which helps impatient souls like me stick to the program. My team has been blessed to have a devops guy who has a scientific mind and acts as informal agile coach while pairing - and he's probably the reason we do a good job on the TDD because he makes us all better at it. If you're at a workplace that is encouraging TDD and pairing, you should be thankful and honestly try to do a great job at it. Your work weeks will be relaxed and you probably won't need to work much overtime. I wind up with lots of left over energy to burn on my home projects, which I appreciate.
- davidjnelson 11y ago
  Jobs like that are indeed amazing. Anyone have an effective strategy for evaluating if a job is like that while interviewing? Or perhaps a list of companies that operate this way? I'll start the list with Autodesk, although all projects and teams are different of course.
100k 11y ago
I found it strange that Martin suggests that the gaps in TDD-style tests with regard to dealing with bad input should be filled by integration tests, which due to their complexity seem more likely to cover the happy path, rather than fuzz testing or quickcheck (https://en.wikipedia.org/wiki/QuickCheck https://en.wikipedia.org/wiki/QuickCheck) style tests.
- davidjnelson 11y ago
  Right, those two tools seem like a natural fit for bad data input testing, and do seem to make more sense at the unit level.
jdking 11y ago
For a new project I like to start by writing code that sketches out ideas of how the software should hang together. TDD at this point is kind of wasteful because if you decide to backtrack or rework aspects of the design then you have to also rework all of the tests. I find that once the design begins to crystalize, adding unit tests at this point is valuable, but not necessarily in a 'test-driven' way. TDD by itself, per se will not automatically produce a good design, and can often produce bad designs with huge proliferation of classes / interfaces that makes a codebase more complex and difficult to understand. TDD is not the be all and end all that some commentators seem to believe.
inaprovaline 11y ago
Every single time a developer releases a piece of code not covered by tests, he/she is basically taking a bet, hoping that things will work. And very often that is simply not the case. Releasing not tested code is simply unprofessional and wrong in so many different ways. I honestly don't see any valid argument to not write tests.
- jqm 11y ago
  Agreed, but writing tests isn't necessarily the same as TDD.
projectileboy 11y ago
TDD is just a tool, not a religion. If the tool works for you, use it. If not, don't. I would encourage people to give it an honest try and see if they find it valuable.
deleted 11y ago
[deleted]
vmorgulis 11y ago
An interesting and simple way to overcome the testing interface design problem with "tracing tests": http://akkartik.name/post/tracing-tests http://akkartik.name/post/tracing-tests
sargas 11y ago
Moral of the story. Choose simple design, and test your code. Am I missing something? Btw, this website is great! I really enjoy the writing approach.

131 points by mxhold 11y ago

> but he said he was just using it for some home projects I think here lies the biggest problem. For small/hackish projects you barely get any benefits from test driven development but still have the higher costs. Test-driven development means that you will spend more effort while developing, but will have to spend less on maintaining in the long run. The fun part about home projects is that you don't really have to think about maintenance at all and you can just hack things away until they work for you. PS: you should write out acronyms once in the beginning of an article

LordDragonfang 11y ago
I spent the majority of the article thinking it stood for the "top-down design" that my intro to programming professor was so fond of.
EdSharkey 11y ago
My home projects become tragic when they get past the trival size and I haven't been TDD'ing and designing all the way through. I think part of my problem is that I cannot devote a consistent level of effort every week to my current home project. Sometimes I'll leave and when I come back to it, I'm lost without a test suite and wind up rewriting huge swaths of it. Really good tests also serve as up-to-date documentation of your design. If you code in Java or Groovy, check out the Spock Framework. Spock tests read like a story. I wish there was a Spock-like DSL for JavaScript development.
- vorg 11y ago
  Spock hacks into Groovy's AST to make labelled expressions have special meanings: def "adder-test"() { given: "a new Adder class is created" def adder = new Adder(); expect: "Adding two numbers to return the sum" adder.add(3, 4) == 7 } It could all easily break if the Groovy parser or AST is updated. And very clunky, which says something about Groovy's design post v 1.5.

robert_tweed 11y ago

Title is slightly misleading, so for anyone reading the comments first, this is Uncle Bob's rebuttal of yesterday's "Giving up on test-first development", in the form of a Q&A. Original discussion here: https://news.ycombinator.com/item?id=11310711 https://news.ycombinator.com/item?id=11310711

me_again 11y ago

Q: Are you sick of the Socratic method? A: Oh God yes. Q: What's wrong with it? A: It's overly verbose, condescending, and allows you to give the appearance of resolving a debate when all you've actually done is talk down to a sock puppet.

ktRolster 11y ago
Q: Why should that be different than any other type of rhetoric? A: If you want truth, read a scientific study, not a blog.
- dave2000 11y ago
  Q. Are there actually proper studies done by and of proper developers writing proper (ie not trivial crap) code which demonstrate the pros and cons of TDD?
  - ktRolster 11y ago
    A. This one is probably good, it compares actual software teams: http://www.infoq.com/news/2009/03/TDD-Improves-Quality http://www.infoq.com/news/2009/03/TDD-Improves-Quality It shows in increase in quality, but with an increase in development time. It is my un-studied assessment that the improvements seen from TDD are primarily a result of the programmers thinking more. It pushes you to think of every edge case. It also gives more experienced programmers a chance to mentor younger programmers (for example, you can easily look at the test coverage and say, "look, you need to test these things too." It's harder to do that (though still possible) without tests).
greenyoda 11y ago
"It's overly verbose, condescending, and allows you to give the appearance of resolving a debate when all you've actually done is talk down to a sock puppet." I agree with your criticism of the article's style. But to be fair, if you're arguing with yourself (as the author is), it's not really the Socratic Method, which is a dialog with another person. If you don't get to control what questions the other person asks, it makes for much a more interesting conversation.

jblow 11y ago

For many paragraphs, I thought this was a parody of TDD defense, but then it turns out it wasn't. His 'defense' of the point is basically: Look, when you do TDD you have to put a lot more work into the tests than you thought! It is not just a simple thing! Okay, fine, but ... Before embarking on TDD, the programmer had a picture in his head of what the costs+benefits of this change would be. Now you are telling him the costs are WAY higher. So a successful defense would have to then make the case that the benefits are also WAY higher. But he doesn't. Because the benefits aren't higher, in fact they are lower (as is the case with every well-intended scheme in the history of anything.) As usual my advice on this is: look at the people who build things you find highly impressive, and study how they did it. This is much more fruitful than reading the output of people who want to spend all day telling you how to program (which leaves very little time for them to build software that is impressive, i.e. they never even test their own ideas!)

howareroark 11y ago
I like your usual advice! I imagine there are a lot of very ingenious things hidden within the code of people who have never written an article. Or even just contradictions to articles that they may have written. I find a lot of articles tend to just build upon common assumptions with a unique twist. Makes sense though, people want to read things that validate their assumptions. People want to write things that people want to read.
aalvarado 11y ago
TDD is better than no tests most of the time I think. So at least that's a gain altogether.
- aalvarado 11y ago
  I do TDD rarely, I like it when I'm on pristine projects, I feel it works when working alone on code you're outside your paying job. Or a library that you don't need to do much exploration programming. I add tests after the fact for most of my programming, usually because that's how I feel more comfortable. Sometimes it is a net win to figure out how something works by experimenting with different ideas and start having a feel of the software you're creating. Without slowing down for trying to think about correctness every time you write something down. TDD should not be, "An always on" kind of thing, I feel like most of what software has taught me is "Use where better suited" which this I think is the main reason why I feel I differ with his view which I think it is, use always. I kind of think that people with those bracelets about "always doing TDD" are thinking.

ryanbrunner 11y ago

There's definitely some good points here, but I have a huge issue with this point: > Something that is hard to test is badly designed. In my experience, TDD has a natural tendency to favour decoupling at all costs, and TDD zealots will push de-coupling units as an unqualified positive. And if your metric is "good design = easily testable and low coupling" it certainly looks that way. This mindset fails to take into consideration the fact that tightly coupled things are often simpler to understand and reason about. They're more closed to extension, sure, and harder to test in isolation, but a straightforward process that acts like a "black box" and performs a job simply in a few lines of code is often better than the class explosion that rigid TDD often encourages. And what's the value of keeping things open to extension if the only thing that is going to reasonably extend them are tests? A good illustration made by DHH as part of one of his anti-TDD tirades is here: https://gist.github.com/dhh/4849a20d2ba89b34b201 https://gist.github.com/dhh/4849a20d2ba89b34b201 Anyone who can honestly say the latter example has a better design has a very different opinion on "good design" than I do.

ktRolster 11y ago
His point, as phrased, is correct though, something that is hard to test is badly designed. You need to be able to test your software in some way or another. Even if you've proven its correctness, you still want to put it through some basic sanity tests (as Donald Knuth pointed out).
- sago 11y ago
  Yes, but it misses the point of the criticism. The issue isn't whether the final product is difficult to test. It should be roughly as easy to test the final product no matter the implementation strategy. The problem is that TDD requires a royal-road of testing. No code can be written without tests for that specific piece of code. So you can only build the whole out of components that are testable in isolation. The claim is that this excludes architectures that don't provide such a step-by-step path of testing. This interacts badly with the 'make everything an API' idea. You end up with these functionally small units with over-engineered APIs rather than something more complex, more efficient, and easier to refactor as a whole.

exabrial 11y ago

Tdd is actual engineering: requirements first, set expectations, plan, estimate, build. Silicon Valley (generalization) has extreme shortsghtedness when it comes to building software, there are a lot of prima donnas, hipsters using whatever is cool,tech decisions made on opinion rather than measurement, and NIH. Have a spine and push for tdd. The prima donnas will attack you ad hominum and call you slow. But it feels pretty damned good to be right.

mikegioia 11y ago
The prima donnas will attack you ad hominum and call you slow. I don't know whether to laugh at or applaud the irony of that statement.
stuartaxelowen 11y ago
actual engineering prima donnas, hipsters have a spine And then... The prima donnas will attack you ad hominum I'm not for or against TDD, but you've gotta see the irony here.
marcosdumay 11y ago
> requirements first, set expectations, plan, estimate, build So, all the process that is known for decades to mostly not work for software?
usrusr 11y ago
That's why conservative engineering traditions mandate that whenever one sets out to design a bridge, the very first thing to do is to build a really heavy car.
- overgard 11y ago
  You also want to make sure your heavy car falls off the leading edge of the bridge before you raise the support structure for that part. So you're sure you're not building unnecessary bridge parts.

facepalm 11y ago

And communism would work if only people would do it properly. It seems to me that kind of argument could be made about anything. "It only didn't work because you didn't do it properly". Doesn't it work for Homeopathy, too? "It would have worked if you hadn't passed it through the x-ray scanner at the airport" or "it would have worked if you had taken the medicine while doing a handstand". In the end doing it right becomes so complicated that you need to hire an expert to do it for you. Wonder if that was the point all along - basically marketing.

Ace17 11y ago
Some disciplines are hard to do properly, and easy to do wrong. It's a mistake to dismiss them just because the return on investment isn't immediate. We're mostly programmers here, we're not supposed to be afraid of steep learning curves!
- facepalm 11y ago
  Sure, although my heuristic for trying new Software methodology tends to be "does it make things simpler?". That article made my head hurt...
jacques_chester 11y ago
The communism analogy is better than the homeopathy analogy. The former makes problematic assumptions about human nature, the latter impossible assumptions about physical reality. That said, I work in a company where TDD is the default. So far everything still works and there are no tanks rolling into any public squares to squash the bourgeois scourge.

barrkel 11y ago

This is an argument against a straw man, IMO; people who have a problem with TDD don't (or shouldn't) have a problem with testing, or creating a design that is testable. What TDD is specifically poor at is design. Test Driven Design literally means your tests drive the design of the system, rather than any other consideration, like reducing API scope, reducing complexity, reducing configurability (yes, excess configurability is a bad thing, and TDD tends to encourage it). TDD in particular won't drive insightful designs, because insight is a product of a fertile and well stocked mind meeting a problem domain - it does not emerge organically out of tests.

sago 11y ago

To me, TDD means: 1. No functionality is coded without a failing test. 2. Only code the minimum functionality to make the test pass. It does not mean 'test more' or 'write tests'. So I'm not sure more than 10% of this 'defence' bolsters the method at all. Seems like the normal rhetorical bait and switch - you pretend that your opponent is criticising testing and respond by defending some more or less vague notion of tests, with no substantive defence of TDD beyond "you didn't try hard enough." The example of the pacemaker, for example, has no relevance to TDD whatsoever.

davidjnelson 11y ago
Don't forget 3. Easily and safely refactor both your production and test code.

overgard 11y ago

Regardless of if TDD works, we see this argument pattern all the time, some magical claim for effectiveness is asserted via a methodology (always anecdotally), someone says "didn't work for me" and the response is ALWAYS "well you didn't do it long enough to get it!" It's all just noise. Theres nothing wrong with having your pet theory, I just wish entire industries wouldn't carelessly hop on board every time some consultant comes up with an acronym and some promises.

EdSharkey 11y ago

Forcing yourself to not write a line of production code without having a test in place to test it first produces a very high level of coverage over all your control paths. You wind up with the tests being an ad hoc specification for the production code. Not really a design as much as documenting the code. This is a really irksome way for me to work, and I find that level of diligence difficult to muster. Often I will find myself writing the production code first and writing tests to cover after the fact. My coverage is probably not as high as it is when I TDD the code. The cadence of TDD'd projects I've worked on professionally is painfully slow and predictable. If you're at a workplace that is giving you the time and resources to do it, then you're likely also pairing, which helps impatient souls like me stick to the program. My team has been blessed to have a devops guy who has a scientific mind and acts as informal agile coach while pairing - and he's probably the reason we do a good job on the TDD because he makes us all better at it. If you're at a workplace that is encouraging TDD and pairing, you should be thankful and honestly try to do a great job at it. Your work weeks will be relaxed and you probably won't need to work much overtime. I wind up with lots of left over energy to burn on my home projects, which I appreciate.

davidjnelson 11y ago
Jobs like that are indeed amazing. Anyone have an effective strategy for evaluating if a job is like that while interviewing? Or perhaps a list of companies that operate this way? I'll start the list with Autodesk, although all projects and teams are different of course.

100k 11y ago

I found it strange that Martin suggests that the gaps in TDD-style tests with regard to dealing with bad input should be filled by integration tests, which due to their complexity seem more likely to cover the happy path, rather than fuzz testing or quickcheck (https://en.wikipedia.org/wiki/QuickCheck https://en.wikipedia.org/wiki/QuickCheck) style tests.

davidjnelson 11y ago
Right, those two tools seem like a natural fit for bad data input testing, and do seem to make more sense at the unit level.

jdking 11y ago

For a new project I like to start by writing code that sketches out ideas of how the software should hang together. TDD at this point is kind of wasteful because if you decide to backtrack or rework aspects of the design then you have to also rework all of the tests. I find that once the design begins to crystalize, adding unit tests at this point is valuable, but not necessarily in a 'test-driven' way. TDD by itself, per se will not automatically produce a good design, and can often produce bad designs with huge proliferation of classes / interfaces that makes a codebase more complex and difficult to understand. TDD is not the be all and end all that some commentators seem to believe.

inaprovaline 11y ago

Every single time a developer releases a piece of code not covered by tests, he/she is basically taking a bet, hoping that things will work. And very often that is simply not the case. Releasing not tested code is simply unprofessional and wrong in so many different ways. I honestly don't see any valid argument to not write tests.

jqm 11y ago
Agreed, but writing tests isn't necessarily the same as TDD.

projectileboy 11y ago

TDD is just a tool, not a religion. If the tool works for you, use it. If not, don't. I would encourage people to give it an honest try and see if they find it valuable.

deleted 11y ago

[deleted]

vmorgulis 11y ago

An interesting and simple way to overcome the testing interface design problem with "tracing tests": http://akkartik.name/post/tracing-tests http://akkartik.name/post/tracing-tests

sargas 11y ago

Moral of the story. Choose simple design, and test your code. Am I missing something? Btw, this website is great! I really enjoy the writing approach.