Approaching RSpec

I'm still thinking about RSpec and how it fits into my testing world (see my other post, but I think I'm starting to build a model that works for me. RSpec is a great design and functional testing tool, it's something that I plan on using as my strategic/longer range tool. Test::Unit still feels like the right way for me to handle the nitty-gritty of TDD and commit to commit work.

I think the right model is something like this:

1. Write out the specs for an iteration — as text first, then convert them to RSpec
2. Look at the spec I'm going to work on and write the simplest test_ method to start making it work
3. Write just enough implmentation code to make my unit test pass
4. Repeat steps two and three until the first spec passes
5. Pick another spec, and repeat steps two and three until it passes
6. Refactor
7. Repeat steps five and six until all my tests and all my specs pass or I run out of time during the iteration

I think this creates a good balance between decoupled testing of what the program does (RSpec) localization of problems (to aid TDD and refactoring). It's more work, but I think I see the benefit. Just in case this wasn't clear enough, I've got a little project that will make a great example.

My son, Mike, just finished writing his first useful Ruby program. It prompts the user for a series of chores (preceded by an arbitraty priority), then prints out an ordered chore list. It's completely procedural and was written without specs or tests, but it's a pretty good effort for a twelve year old.

I'll be writing a series of posts around it as follows:

1. Create a specification for the existing program, and refactor the program to be testable.
2. Write unit tests for the refactored program.
3. Write a specification for a new feature.
4. Implement the new feature in a TDD style, with my backing specification.
5. Review the process

I hope they'll provide a clear example of my thoughts.