3 ms·
The best example I can think of on this, is to look up that TDD creation of a Sudoku solver. This is collected in an old HN post at https://news.ycombinator.co
by taeric 4y ago
The best example I can think of on this, is to look up that TDD creation of a Sudoku solver. This is collected in an old HN post at https://news.ycombinator.com/item?id=3033446 https://news.ycombinator.com/item?id=3033446.
It is reasonable to think you can know what functionality you need to test. And, for certain, if you know the boundaries of the system you are building, you will know some. That said, there is a tendency to build more boundaries than needed in our industry, period. Would be like a community garden that thought they should arrange things by type of plant that will be created by the community. When the actual divisions should be on how many community members you will have.
- BoiledCabbage 4y ago> The best example I can think of on this, is It's not the best example. It's the one well worn example that everyone pulls out and is a perfect case of letting perfect be the enemy of good. Something works for 99% of cases, someone finds a 1% case it doesn't work for an says "ok I don't need to evaluate it it's useless". Not tool works 100% of the time, the fact that it didn't work for someone creating a constraint solver is effectively irrelevant.
- taeric 4y agoFair, "best" is clearly the wrong word there. A pointed example, then? :D That said, I'm more than game for alternative examples. Have any that show benefits? Most examples I ever see fall, at best, into drawing the rest of the owl.