Selleo Labs spółka z o.o.

When preparing our test suite we might be tempted to make some shortcuts that will render our tests less readable, comprehensible or will significantly decrease the flexibility of further implementation.

Ruby On Rails Testing Antipatterns

I help our CTOs, Development Leads, Product Owners and business executives to design and build scalable and maintainable systems. With over 13 years of experience gained on software development projects delivered to international clients, I am able to enhance the productivity of software development teams while creating data collection, processing and analysis tools.

Błażej Kosmowski

\[TOC\]  
  
When preparing our test suite we might be tempted to make some shortcuts that will render our tests less readable, comprehensible or will significantly decrease the flexibility of further implementation. Below, I try to list some of the most commonly seen techniques we should avoid to keep our test suite healthy. Please be advised, that examples provided are usually oversimplifications helpful to highlight the discussed issues.

## Testing private methods

The bad thing about testing private methods is that it should not actually happen as naturally, we should be testing public interface instead. This may indicate, that either tests were written after implementation (what is an antipattern itself) or public interface was changed at some point into private interface. The consequence of testing private methods is code resistant to refactoring, as implementation become tightly bound to correlated tests.

To counter testing private methods directly, we should always test public interface that uses them (so private methods are tested indirectly). The use of a test coverage tool (e.g. simplecov) might become handy in the detection of private methods that are not tested (and therefore possibly never used). Also behavior-driven development (BDD) is a technique that naturally encourages testing public interface only.

<Gist id="31c821fd62379aebc82d61976cc1c8e6" />

## Stubbing framework methods

Stubbing framework methods is a great way to leave yourself as little choices during implementation as possible which is not a positive thing. For sake of simplicity, consider the following snippet:

~~~
allow(User).to receive(:where).with(name: “Tony”) {         
  [instance_double(User, name: “Tony”)] 
}
~~~

By stubbing framework (in this case `ActiveRecord` query interface), we are forcing ourselves to exactly one way of implementing a requirement, with little place for any refactoring.

Instead of stubbing a framework features, just use factories (or other techniques) to provide framework with data it needs. In the case shown above, simple `create(:user, name: “Tony”)` would be sufficient.

<Gist id="977d3799dda3c109890d8e4659bdf3ff" />

## Stubbing library methods

Stubbing library methods is very similar to stubbing framework methods, but it brings other kind of problems to the table. Libraries evolve much faster than frameworks and are prone to frequent changes. Also, it is not uncommon to change one library into another one due to various reasons. If we depend on stubbing public interface of a library across the system, we might need to update our tests in many places every time our library evolves or we decide to change it into a different one.

In order to mitigate this problem, it is a good idea to provide a wrapper (facade) around the given library and then stub only interface introduced by this library. Then, it might be right to stub library methods within tests for the wrapper but usually, it is even better to mock something the actual library depends on (i.e. HTTP traffic).

<Gist id="7c8f1185985a3fc48fe1ab5a3b6820ad" />

## Low value tests

Some tests do not bring any significant value and only focus on implementation details. Such tests should be removed in favor of the details being tested indirectly by means of other tests. Testing attributes presence, simple migrations or [relationships](http://blog.davidchelimsky.net/blog/2012/02/12/validations-are-behavior-associations-are-structure/) are good examples of specs that really bring little value to the table and just bloat our tests suite.

## Tests oriented implementation

By tests-oriented implementation we mean pieces of code that exist solely to make specs pass, but do not bring any functionalities or business logic. Anytime we see if `Rails.env.test?` wherever in our codebase, it should raise our suspicions. A code that conditionally runs only in test environment not only increases perceived complexity, but also might make our tests unreliable. Therefore, we should only allow such conditionals in tests implementation and code related to project configuration and initialisation.

## Test induced design damage

A bit similar problem is test induced design damage. To cut the long story short, this is making code/architecture less readable and comprehensible as a result of making it highly testable in isolation, easier to test-first or making the test run faster. There is a [great article by DHH](http://david.heinemeierhansson.com/2014/test-induced-design-damage.html) shedding more light on the topic.

When preparing our test suite we might be tempted to make some shortcuts that will render our tests less readable, comprehensible or will significantly decrease the flexibility of further implementation. Below, I try to list some of the most commonly seen techniques we should avoid to keep our test suite healthy.

RubyOnRails Testing Antipatterns — Part 1/2

\[TOC\]  
  
In [part 1](https://selleo.com/blog/rubyonrails-testing-antipatterns-part-1) we have covered antipatterns related to stubbing and problem with implementation details that are a overcomplicated just for the sake of being super easy to tests. In second part we are going to focus more on tests themselves.

## Overusing framework / library methods

The consequences of overusing framework or library methods when writing specs are similar to those of stubbing library methods. It might be ok to use ORM features to find a record now and then, but the more complex methods we use to facilitate writing of our specs, the more change resistant they become. It might happen, that updating a library our project depends on, breaks tests without breaking actual implementation. Also, using complex methods might hide some of the intentions that otherwise would make tests more comprehensible.

As mentioned before, using simple methods from a framework or other libraries won’t hurt, but usually we should be using just language / standard library features in their simplest form. When it is necessary to use library of some kind to facilitate our tests, it might be a good idea to wrap the usage in a helper method or matcher that will make its use more readable and comprehensible.

<Gist id="43a4ac7e3ef22972d0e6bf706bb0d060" />

## Overusing feature tests

Feature tests (system tests / integration tests) are a very powerful tool used a lot when following behavior-driven development approach. Still, those can be easily overused, especially if we use them to test all side-effects and exceptions. Not only feature tests require more code (both setup and assertions), but are also much slower than unit tests. What is more, it might be also more difficult to identify reasons behind some bugs due to low tests granularity.

In order not to overuse feature tests, we need to understand what is the main reason for writing them. In BDD the main reason is to have some starting point for further development. Another one, regardless of our following BDD or not, is that feature tests act as a high-level safety net, ensuring happy-paths within our application are working fine. If we use feature tests solely for those two purposes, and we write lower-level (unit) tests for other cases, we should end up with the right balance between the both kinds.

<Gist id="aef738fb9a4180cf485bcb977b303b3c" />

## Optimizing tests too much

Refactoring test suite to the point where nothing is duplicated and everything is written in the shortest, most compact way possible, might be tempting at first, but may backfire in the long term. Using loops, complex helpers, shared examples and contexts are just a few ways to achieve very slim tests implementation. One could argue that it makes tests more maintainable, as each update will require less and smaller changes, but in my opinion, there is more to maintainability than just simple amount of code. I opt to look at maintainability as an effort required to make a change. This involves understanding and finding what needs to be changed, ensuring whether it is safe to apply the change without unexpected side-effects and then introducing the change itself. The “smarter”, sophisticated and optimized your tests are, the less time making actual change it will take, yet more time might be needed during the preparation for it. The alternative approach to highly optimized tests is to write readability-oriented ones. More on the topic can be found in my another article — [An opinionated guide to readable rspec](https://medium.com/selleo/an-opinionated-guide-to-readable-rspec-part-1-of-2-fe1dce79a478), but even without taking it to the extreme, sometimes adding some extra description or tolerating a bit of duplication can change a lot.

## Overtaking tests with implementation

It is a highly tempting practice. Let’s imagine we implement a simple listing in a TDD approach. In attempt to make our tests green we fetch records from DB. But hey! We know we will need those ordered by name, so why not include a short, simple `order(name: :asc)` while we are here. Well, tempting as it might be, such practice (implementing more than necessary) can result in code that will remain untested. To make matters worse, such a code in most cases will not be detected by a code coverage tool as untested, and therefore, we won’t know whether we need to add missing tests unless we do it right afterwards.

To counter this situation, we need to make sure that all implementation is driven by tests failing first. Anytime we are able to remove a piece of code without turning test suite red should signal the necessity of writing missing specs or a possibility of code removal. As usual, there might be cases of code we do not need to test due to some reasons, but this should always be a conscious and not accidental choice.

<Gist id="6d27017232310db14bf88320ea722913" />

## Including irrelevant data

Including irrelevant data in setup of our tests usually decreases their readability. This happens not only because the size of actual setup is larger than necessary, but also one might find it confusing by being encouraged to find correlations between data and assertions that are simply not there.

Usually it is enough to just consciously stop practice of including irrelevant data when preparing setup for tests, but sometimes this data is necessary because it makes an object or set of objects valid. In this case, we should follow a rule of a thumb to prepare our factories in such a way, we end up with valid objects by default (without providing any attributes explicitly). This will allow us to hide the irrelevant data in factories. To ensure we always end up with valid objects when producing those using factories, we can enable factories linting.

<Gist id="c1aa09e51f9316f4da61bf1c7260676d" />

## Summary

Many of problems presented above are very unlikely to happen if one follows behavior-driven development approach to testing, hence following BDD is highly recommended. Finally, while to every rule there is an exception, keeping in mind a few antipatterns we should be aware of can vastly improve quality of our test suite in the long term.

In part 1 we have covered antipatterns related to stubbing and problem with implementation details that are a overcomplicated just for the sake of being super easy to tests. In second part we are going to focus more on tests themselves.

Read our blog fueled by years of development experience

Business

Technology

Ruby On Rails Testing Antipatterns

RubyOnRails Testing Antipatterns — Part 1/2

RubyOnRails Testing Antipatterns — Part 2/2

Tell us about your project

Company

Our Services

Blog

Other Services

Countries

Awards & Certificates