3 ms·
Peter Norvig's approach seems like the textbook way to TDD: 1. Find a large body of known good input/output pairs 2. create tests around that known good data 3
by voodootrucker 8y ago
Peter Norvig's approach seems like the textbook way to TDD:
1. Find a large body of known good input/output pairs
2. create tests around that known good data
3. create an implementation that produces the desired output from the given input
There's no reason Peter couldn't or shouldn't have started with the tests.
- quanticle 8y agoWhat you're describing is closer to what Ron Jeffries attempted than to what Peter Norvig did. It's Jeffries who started with input and output and then faffed about for five blog posts while attempting to figure out a way to get input to match output. What Norvig did was start by thinking about the representation of the problem and the constraints that the problem imposed. He then found a way to elegantly represent those constraints in code. And, only then did he write tests. Moreover, the process you describe is quite similar to the parody of "how to draw an owl" [1]. It completely glosses over the fact that "create an implementation that produces the desired output from the given input" is where 99.5% of the complexity lies. [1]: https://i.kym-cdn.com/photos/images/newsfeed/000/572/078/d6d.jpg https://i.kym-cdn.com/photos/images/newsfeed/000/572/078/d6d...