3 ms·

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 cha

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.
  - pmarreck 10y ago
    > complex sequences of state mutations. Which is where immutability and functional programming win... coupled with TDD you get a major delivered-bug reduction
    - jeremiep 10y ago
      You have state even in functional programs. My original point was about simplifying the program so it is easier to reason about in the first place, rather than write tests for a yet-to-be-overengineered-mess :) What if you get very tight memory/cpu constraints and FP/immutability isn't available/affordable? What if your programs runs on millions of networked nodes simultaneously? GUIs are still very stateful even with FP for one! So if you're going to write property-based tests after you know what the properties of the system are, and these will cover way, way more cases than you'll ever think of writing tests for manually, why even bother? What I do see is people deluding themselves into thinking their software is reliable when it definitely isn't and they're now even less careful when developing because they've got tests to protect them.

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.
- pmarreck 10y ago
  > complex sequences of state mutations. Which is where immutability and functional programming win... coupled with TDD you get a major delivered-bug reduction
  - jeremiep 10y ago
    You have state even in functional programs. My original point was about simplifying the program so it is easier to reason about in the first place, rather than write tests for a yet-to-be-overengineered-mess :) What if you get very tight memory/cpu constraints and FP/immutability isn't available/affordable? What if your programs runs on millions of networked nodes simultaneously? GUIs are still very stateful even with FP for one! So if you're going to write property-based tests after you know what the properties of the system are, and these will cover way, way more cases than you'll ever think of writing tests for manually, why even bother? What I do see is people deluding themselves into thinking their software is reliable when it definitely isn't and they're now even less careful when developing because they've got tests to protect them.