I often come up with test cases (just the cases, not the actual logic) while writing the feature. However I am never in the mood to context switch to write the test, so I'll do the bare minimum. I'll flip over to the test file and write the `it()` boilerplate with the one-line test title and flip back to writing the feature.
By the time I've reached a point where the feature can actually be tested, I end up with a pretty good skeleton of what tests should be written.
There's a hidden benefit to doing this, actually. It frees up your brain from keeping that running tally of "the feature should do X" and "the feature should guard against Y", etc. (the very items that go poof when you get distracted, mind you)
I seem to remember this being mentioned in the original TDD book. To brain dump that next test scenario title you think of so as to get it out of your head and get back to the current scenario you are trying to make pass. So by the same idea as above, to not context switch between the part of the feature you are trying to get to work.
By the time I've reached a point where the feature can actually be tested, I end up with a pretty good skeleton of what tests should be written.
There's a hidden benefit to doing this, actually. It frees up your brain from keeping that running tally of "the feature should do X" and "the feature should guard against Y", etc. (the very items that go poof when you get distracted, mind you)