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:
- Write out the specs for an iteration — as text first, then convert them to RSpec
- Look at the spec I'm going to work on and write the simplest test_ method to start making it work
- Write just enough implmentation code to make my unit test pass
- Repeat steps two and three until the first spec passes
- Pick another spec, and repeat steps two and three until it passes
- 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:
- Create a specification for the existing program, and refactor the program to be testable.
- Write unit tests for the refactored program.
- Write a specification for a new feature.
- Implement the new feature in a TDD style, with my backing specification.
- Review the process