Notes from Effective Testing with RSpec 3, chapter 5.
Martin Fowler’s article on Unit Tests defines them with the properties:
small scope, done by the programmer herself, and fast — mean that they can be run very frequently when programming.
Effective Testing & RSpec also take this philosophy. What differentiates Unit Tests from others is the degree of isolation. If the dependencies allow, we focus on just the class. Otherwise, we may need to focus on a set of classes for a specific behavior.
This is where Effect Testing has taken a left turn. With the majority of my projects being in a Rails context I think of Unit tests as the Model layer in a MVC framework. In this chapter, we practice Unit Tests at the request/controller layer.
Typically, you test a class through its public interface, and this one is no exception. The HTTP interface is the public interface.
Excerpt From: Myron Marston, Ian Dees. “Effective Testing with RSpec 3.”
I’m pretty stuck in my thinking of what a Unit Test is. This is helping me redefine it. They’ve linked to Xavier Shay who dares to toss the templated test directory and replace them with a different structure.
Unit Tests aren’t specifically for models but any object. Integration isn’t just for controllers but code operating against code that cannot change; usually helpers and presenters. Xavier tosses Functional in favor of Acceptance.
While different, this still feels natural. What category of test you want to run will depend on where you’re working in the codebase. This categorization of tests is another mental layer of filtering, which is important. It’s how we automate a necessary level of tests while still being efficient with test driven development.
We are advised to watch Gary Bernhardt’s talk on boundaries. I wanted to include it here because Gary provides a great example of how a difficult test demonstrates a refactoring opportunity in the codebase.