An admirable goal.
Sometimes, admirable seems impractical. Testing takes time, and writing tests before code requires understanding both the code and the tests.
But the evidence is clear: with experience, "test first" results in better designed software, with architecture that is maintainable and scalable. Almost by definition. However, there are many kinds of tests.
At the East Bay Rails March[masked] Meetup, we're going to look at a specific type of "behavior-driven" test called "outside in."
"Outside in" means we're going define a sequence of events modeling a user's interaction. We're going to write these events in an easy-to-understand domain-specific language (read like Plain English). Then we're going to "drive out" a fresh Rails application to pass these test. Some details:
- Pure outside-in, starts from a Cucumber feature file on a bare Rails application.
- No RSpec, pure Cucumber w/Capybara matchers.
- Should take 60-90 minutes to get through. Follow along with your own Rails application.
- Material based on an article written by Sarah Mei (Pivotal Labs) a couple of years ago, and updated for Rails 3.1 with material from a Pragmatic Programmers book.
- It's fun!
Seriously, driving out test code can be a blast. You do all the hard work up front, which is figuring out what code you want to write. Once you know what to write, the writing of it easy. Just write code until all the tests pass.
Hope to see you there!