Your app is a unique snowflake. Your tests are too… but they shouldn't be!
Years helping teams write better tests has taught me one thing: consistency is crucial. Inconsistent tests slow teams down, wasting time to understand how each test works. Deciding on conventions—even arbitrary ones—can prevent tremendous pain later.
This talk will introduce a ready-to-fork Test Style Guide of carefully-considered rules and templates for Rubyists. You can customize it to fit your preferred tools, too. Soon, you'll be on your way to having more consistent tests that are much more fun to maintain!
This talk will make a brief pitch about why inconsistent tests are an important problem to most Ruby teams and then spend most of its time carefully walking through an example style guide for any project's test suite (akin to a CONTRIBUTING.md). The guide will be designed to be easy to adopt, enabling developers to drop it in a repo, tweak it, and start adhering to it.
The advice will be relatively firm and prescriptive regarding critical underlying concepts our community has learned about clear tests (like Arrange/Act/Assert, choosing strict rules about how to use test doubles, etc.). The guide will be looser about which test suites (e.g. isolation vs. unit vs. smoke vs. feature) to write for a given app, because advice will vary based on the context of the situation. Finally, the guide will be looser still on which tools it selects as default choices, both because people tend to have strong preferences and because the tools we use are secondary to the value we can gain by using them consistently.
For example, in the presentation I may illustrate how the prescribed testing styles might apply to Minitest, Mocha, and Rails Fixtures; later, I may demonstrate how the same rules would look when applied to a toolset of RSpec, RSpec-given, Gimme, and Machinist or FactoryGirl. The goal isn't to judge an individual's favorite tools as faulty, but to shine a light on how more disciplined use of our tools—whatever they are—can lead to easier-to-maintain test suites
The most important takeaways from the talk will be to instill in the audience a sense of urgency for arriving at a consistent approach to testing, and to have equipped them with a workable set of defaults to put such a set of conventions in place quickly. I am very hopeful that this talk will have the opportunity to improve how many Rubyists look at testing.
I've spent nearly a decade following the Ruby community as it continues to sit at the forefront of innovation in testing tools and theory. I remember when many luminaries of testing left Java for Ruby and brought with them a culture of writing lots of expressive tests for our code. But behind the abundance of choice we have as Rubyists (e.g. whether to use RSpec or MiniTest, when to incorporate Cucumber or Capybara, which test double library to use, how to control test data with fixtures or factories, how to isolate our tests from third party services with WebMock or VCR), there lies a problem: our test suites tend to be complex, slow, and—most importantly—inconsistent.
I've been on teams with over 90% code coverage but who absolutely hate their test suites and only wish they could delete them all. Over time, I've seen patterns emerge that predict when a team's tests will become slow, confusing, and hard-to-maintain; as a result, I've absorbed a lot of really good advice about how to write clear, easy-to-read tests.
It's 2015, and most developers can proudly say that their code is thoroughly tested. The next frontier is to ensure our tests are also a delight to maintain long-term, by narrowing our focus amid countless testing tools and theories to a clear and consistent approach.
Love the talk. Everything title down is perfect.
Meh to the title; you can do better.
Some inspiration: http://tenbullets.com/