David Newton wrote:I'm pretty sure I can handle specs.
Ah, so you've broken the code! :) Although I should have known better than to question your abilities since you mention you're a 'Polyglottal Developer' right in your signature.
(No sense in declaring "expected", though, and it makes the test harder to read. Plus you don't always use it anyway.)
You're right of course. Point taken.
TDD and BDD are the same: write the most minimal test case that fails, write the code to make it pass. The output of a program is a large-scale behavior, and tests written for it will not pass until the sub-behaviors pass. That you were writing the large-scale behavior test first suggests you either (a) didn't test during development, or (b) expected it to fail for a long time while the actual code was developed.
The answer is (b). The way I decide what low-level behaviors to implement is to start with the high level abstraction, and then break that down into smaller and smaller problems until I get to a problem I can implement. What I like about the top-down approach is that I feel like it keeps me focused. The problem with that approach is that as you pointed out the tests will fail for a long time. (I'm sure there are other problems too, but that is the most obvious one to me).