3 ms·

Bad programmers are going to make a mess of things no matter how many tests you have. More often than not I see tests as needlessly solidifying the architecture

Bad programmers are going to make a mess of things no matter how many tests you have. More often than not I see tests as needlessly solidifying the architecture prematurely. More often than not I see TDD yielding horrible, terrible software architectures and at that point you do need tests to maintain the resulting mess. TDD somehow assumes emergent architectures and I know from experience this is the worst way to architect something. NPM for example is full of well-tested libraries with poor architecture and bad usability (could be why everything is reinvented every 6 months) but I wouldn't call that a success story. I'm willing to bet the bug reduction from the extra time upfront doesn't come from doing TDD but actually thinking about the requirements and how they fit the larger picture. I really like the following story to illustrate this point: http://ravimohan.blogspot.ca/2007/04/learning-from-sudoku-solvers.html http://ravimohan.blogspot.ca/2007/04/learning-from-sudoku-so...

pmarreck 10y ago
That blog post simply shows that Ron Jeffries failed to understand the core problem of "how to solve Sudoku puzzles" (or lost interest before he succeeded, which explains why he spent so much time on the data representation aka "bike shedding" or "yak shaving") and is no indictment of TDD, which is not a magic elixir that allows you to "organically" solve every possible problem. > horrible, terrible software architectures 1) Need an example. 2) There is no evidence that the architecture would have not been even MORE horrible AND terrible without the TDD involvement > needlessly solidifying the architecture prematurely As all code (whether "test code" or "tested code") is wont to do. Perhaps the fallacy here is considering test code as a separate, "optional" entity in your codebase instead of as an integrated proof of it working as advertised. > willing to bet the bug reduction ... comes from thinking about the requirements Still not an argument against TDD. If anything, that's an argument FOR it. The difference being at the end of the day, you have a working proof of the satisfaction of your requirements. Whiteboarding and TDD are not mutually-exclusive. I don't think that TDD at all implies "not thinking about the problem" nor does using it turn a crappy programmer (who would tend to choose terrible designs over better ones) into a good one. I think you are still constrained by the skill of the programmer no matter whether you use TDD or not. As TDD is just human-produced code, like all code. NPM could have had lots of fresh out of college monkeys work on it for all I know. It certainly wouldn't surprise me. You're right that TDD won't fix being an inexperienced programmer, but that's not an anti-TDD argument, that's an anti-inexperienced-developer argument. Lastly, you failed to address the other arguments I made in favor of using TDD (note: there's some conflation here between "unit testing" in general and TDD specifically unfortunately)
- jeremiep 10y ago
  Lets just take GUI then, how can you design that using TDD? Lets say you've got a multiple steps form where the user can go back and forth between steps and change data anywhere. How are you going to test for ALL possible flows, which are counting in the millions by now. Software reliability doesn't come from testing the obvious use-cases and calling it a day. You'd get the same result by just booting the program and having all these functions execute. Bugs are always going to be in the use-cases you didn't think to test, and there's always going to be orders of magnitude more use-cases than tests. What is incredibly hard to get right are complex sequences of state mutations. This is where most of the bugs are going to be and this is where TDD breaks badly. I'm not saying unit tests and TDD are bad, I'm saying they're overrated. They're one tiny tool you get to verify the reliability of your software and for a lot of application domains they are completely useless. More often than not I see pro-TDD people not knowing concepts like property-based testing which actually can model complex user interactions. And once they learn about it their architecture is already crippled by having TDD drive the design of individual components but not the whole thing and now there's no sweet spot to hook generative testing or reason about the program as a whole.
  - pmarreck 10y ago
    How to TDD a GUI: http://stackoverflow.com/questions/382946/how-to-apply-test-driven-development-for-gui-applicationvc-mfc http://stackoverflow.com/questions/382946/how-to-apply-test-... It works. I would have posted this response yesterday, but when I went to the stackoverflow link at the time, they were actually down :O
    - jeremiep 10y ago
      These answers point to dead links and reeks of Agile. They mention frameworks and MVC variations; from the start they've already bloated whatever they're building and none of them address the real problem: complex sequences of state mutations. So not only are they having software that's orders of magnitude more complex than it should be, they're also completely avoiding the hard problems. You won't see a test like "enter a username, dont wait for server validation, enter an invalid email, optimistic updates, fix email, more optimistic updates, server response & state merges, advance to step 2, 3, come back to step 1, change email, advance to step 4, crash.. wat?!" That's where the bugs are. Not "click the button and the popup opens" because that's trivial. You're also probably not testing that button while a menu is open, or a dialog already opened, or between optimistic updates and server responses, or the combinations of these, or ALL the cases you're going to forget. You're not going back to test each new feature against every single possible state the app can be in. That's why I say TDD is overrated because the problems it fixes are trivial and it ignores the important ones.
deleted 10y ago
[deleted]
deleted 10y ago
[deleted]
deleted 10y ago
[deleted]

pmarreck 10y ago

That blog post simply shows that Ron Jeffries failed to understand the core problem of "how to solve Sudoku puzzles" (or lost interest before he succeeded, which explains why he spent so much time on the data representation aka "bike shedding" or "yak shaving") and is no indictment of TDD, which is not a magic elixir that allows you to "organically" solve every possible problem. > horrible, terrible software architectures 1) Need an example. 2) There is no evidence that the architecture would have not been even MORE horrible AND terrible without the TDD involvement > needlessly solidifying the architecture prematurely As all code (whether "test code" or "tested code") is wont to do. Perhaps the fallacy here is considering test code as a separate, "optional" entity in your codebase instead of as an integrated proof of it working as advertised. > willing to bet the bug reduction ... comes from thinking about the requirements Still not an argument against TDD. If anything, that's an argument FOR it. The difference being at the end of the day, you have a working proof of the satisfaction of your requirements. Whiteboarding and TDD are not mutually-exclusive. I don't think that TDD at all implies "not thinking about the problem" nor does using it turn a crappy programmer (who would tend to choose terrible designs over better ones) into a good one. I think you are still constrained by the skill of the programmer no matter whether you use TDD or not. As TDD is just human-produced code, like all code. NPM could have had lots of fresh out of college monkeys work on it for all I know. It certainly wouldn't surprise me. You're right that TDD won't fix being an inexperienced programmer, but that's not an anti-TDD argument, that's an anti-inexperienced-developer argument. Lastly, you failed to address the other arguments I made in favor of using TDD (note: there's some conflation here between "unit testing" in general and TDD specifically unfortunately)

jeremiep 10y ago
Lets just take GUI then, how can you design that using TDD? Lets say you've got a multiple steps form where the user can go back and forth between steps and change data anywhere. How are you going to test for ALL possible flows, which are counting in the millions by now. Software reliability doesn't come from testing the obvious use-cases and calling it a day. You'd get the same result by just booting the program and having all these functions execute. Bugs are always going to be in the use-cases you didn't think to test, and there's always going to be orders of magnitude more use-cases than tests. What is incredibly hard to get right are complex sequences of state mutations. This is where most of the bugs are going to be and this is where TDD breaks badly. I'm not saying unit tests and TDD are bad, I'm saying they're overrated. They're one tiny tool you get to verify the reliability of your software and for a lot of application domains they are completely useless. More often than not I see pro-TDD people not knowing concepts like property-based testing which actually can model complex user interactions. And once they learn about it their architecture is already crippled by having TDD drive the design of individual components but not the whole thing and now there's no sweet spot to hook generative testing or reason about the program as a whole.
- pmarreck 10y ago
  How to TDD a GUI: http://stackoverflow.com/questions/382946/how-to-apply-test-driven-development-for-gui-applicationvc-mfc http://stackoverflow.com/questions/382946/how-to-apply-test-... It works. I would have posted this response yesterday, but when I went to the stackoverflow link at the time, they were actually down :O
  - jeremiep 10y ago
    These answers point to dead links and reeks of Agile. They mention frameworks and MVC variations; from the start they've already bloated whatever they're building and none of them address the real problem: complex sequences of state mutations. So not only are they having software that's orders of magnitude more complex than it should be, they're also completely avoiding the hard problems. You won't see a test like "enter a username, dont wait for server validation, enter an invalid email, optimistic updates, fix email, more optimistic updates, server response & state merges, advance to step 2, 3, come back to step 1, change email, advance to step 4, crash.. wat?!" That's where the bugs are. Not "click the button and the popup opens" because that's trivial. You're also probably not testing that button while a menu is open, or a dialog already opened, or between optimistic updates and server responses, or the combinations of these, or ALL the cases you're going to forget. You're not going back to test each new feature against every single possible state the app can be in. That's why I say TDD is overrated because the problems it fixes are trivial and it ignores the important ones.

deleted 10y ago

[deleted]

deleted 10y ago

[deleted]

deleted 10y ago

[deleted]