Four Key Reasons to Learn Markdown
Back-End Leveling UpWriting documentation is fun—really, really fun. I know some engineers may disagree with me, but as a technical writer, creating quality documentation that will...
Don't Settle on Just One Test Framework!
At Highgroove Studios, we’re hyperspecialists in Ruby on Rails web application development. Not only do we write amazingly complicated code on time and on budget, but we follow up all our work with tests so we know our code works.
This is not without its problems however, as a test suite can become just as bloated and difficult to update as the code base it tests! This week, I’ll talk about some of the ways I’ve learned to approach writing tests.
Since I began working for Highgroove Studios back in April, I have been innundated with the importance of thorough and reliable testing. Given the culture of performance and quality at Highgroove Studios, I knew that I had to find a way through the maze of test frameworks and options.
After struggling with some very large, brittle test suites, it dawned on me that good test design, just like designing the application itself, was the key to success. Maybe challenging some of my own assumptions about testing was in order as well!
Once I realized that I needed to focus on writing better tests, instead of writing them faster and getting them to pass, I turned to Google and found some really good stuff that I wanted to share:
- Cucumber Blog
- Cucumber Issue Tracker on Github
- Cucumber Style Guide
- Essay on TDD and Agile methodology
- Rspec Best Practices
What all of this information made me realize was that I was trying to accomplish all of this with just a single test framework and certain ones align to Test Driven Development (TDD) and Acceptance Testing (BDD – Behavior Driven Development) better than others do. (Figure 2 in the AgileData link explains visually why I was wrong!)
After spending the time pondering my own practices, I decided to split apart the two tasks (BDD, and TDD) into Cucumber and Rspec tests, respectively. After making the switch from an all-or-nothing, single test suite mentality to a “use what works best” mentality I’ve seen both the quality and ease of coding of my test increase. Its amazing what happens when you stop trying to cram a square peg through a triangle hole!
I prefer both Rspec and Cucumber for TDD and BDD, but you might have a different method. If so, what is it and how does it make your day-to-day test writing simpler and more efficient?
