3 ms·
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 build
by 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 agoYou 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.