10 ways to speed up RSpec using Capybara and FactoryGirl

Tests are usually biggest bottleneck in any system. Here are 10 ways to speed up RSpec  with Capybara

#10 Avoid writing to the database

Lets take simple example.

Anatoly Spektor

Let me help you!

Hey, I am Anatoly, founder of this blog. I would love to help you! I have 6+ years experience in Web Development and IT Leadership. Lets work together on your project! Leave me your email and I will schedule a FREE Consultation!

I have this test:

I am testing if Address is valid by passing a Factory with dummy data.
When I run this test in console I get this:

0.022777 For testing a single test is quit expensive, considering that I don’t have any validation on it. Why it is slow? It is slow because it writes to the database!

How to fix it ? Don’t write to DB when you don’t have to!

Lets fix this example and change 

to

When we replace create with build_stubbed by building address all associations are created, but model is not saved to the database.

Want to learn more about build_stubbed? There is an amazing blog post by Josh Clayton about using build_stabbed for faster tests.

Lets run RSpec again and now we see:

TWICE FASTER! All we did – we did not write to database.

Note: There are cases when you need to test if data is saved into a database (e.g testing object uniqueness), in this case writing to db would make sense.

However, often, we save into database when we really don’t have to.In this case we should ask ourselves – is it really a unit test? Or is it an integration test that tests integration of app and database ? Confused ? Keep Reading!

#9 Run tests wiser

When you application grows, inevitably you will find that your test suite will become slow and optimization will not make much of a difference.

Why bigger test suites are slow ?

Because if we want to have a test suite  that is complete, we will also include integration (feature) tests and no matter what you do – integration tests will be slow.

Why integration tests are always slow?

Because they test integration of the components.  Often integration tests are actually browsing your website, so they are dependant on JavaScript load, on network connection etc.

When I say slow – I mean test suite can be 10 minutes slow!

Running tests for 10 minutes is very inefficient. Main goal of running a test suite is to make sure that the new code does not break the existing code. So if test suite runs for 10 minutes every time – developers probably won’t run  test suite at all.

What to do when big test suite is very slow?

Note: For this solution to work you need to have a strong Unit Test coverage (at least %70).

I have a hack that I have been using for some time now. It does not really solve the problem, but it makes process more efficient.

What you want to do is to run integration tests only when you integrate.

How will that work in real world?

Team of 5 people are working on different branches. While they are working – they run unit tests which are quick and make sure they all pass. Whenever fix/feature is ready it is merged into integration branch – this auto triggers CI to run both unit tests and integration tests (sort of smoke testing). Thus you can work efficiently on your feature branch, and you are covered with smoke testing when you integrate.

At this point you are probably screaming – SHOW ME THE CODE!!!!!

It can look something like this:

To run integration tests do:

To run unit tests do:

To make sure it works nicely  move all your specs that deal with database, email and other slow tests to ./spec/integration.

You might ask: When you say slow tests, how do I know which tests are slow ?

This brings us to the next point…

#8 Profile Specs and  Optimize slowest tests

It is important to know which tests are slow. RSpec provides a feature to profile your test suite and show you 10 slower running tests.

To make it work just go to .rspec file and add –profile . Next time you run your test suite, RSpec will output top 10 slowest tests in your  suite.

On the same note – it is crucially important to follow your code coverage. SimpleCov gem will help you with that.

#7 Use Ruby 2.1 and up

Not much to talk about here. Upgrade Ruby to 2.1 because it is has better memory management. Some say it is up to %15-%20 faster. So if you want to boost your test speed  this could be very beneficial.

More on update to Ruby 2.1 in this awesome post by Justin Weiss

#6 Mock External API’s

What are API requests ?

Examples of API requests : you send a request to twitter to get followers, you query google map for coordinates, you interact with your internal services via API or anything else that makes a network request and waits to get data in return.

Lets get it straight – API calls are slow! They depend on your network connection, on receiver etc. They need to be mocked!

To achieve that in Rails, I have been using webmock gem. The beauty of this gem is that when it is setup, it disables all external calls by default and throws an error if you try to connect to external API. This can be very useful in identifying external places in your code where you actually do real api calls.

#5 With Database Cleaner – use :transaction where possible

I think Avdi Grimm explained this issue best in his blog post on configuring database_cleaner . I highly recommend you to read it. Here is a quick recap: tests that have to deal with database need a way to cleanup dummy data , for that reason devs often use database cleaner gem. Database cleaner is very smart and uses multiple strategies to take care of wiping out data. Two strategies of database cleaner are transaction and truncation.

Truncationwipes all the data after each test.

Transaction – keeps data in transaction and just rollback instead of wiping out. Since rollback is much faster than truncate it is preferred to use transaction strategy. Note there are issues with transaction strategy in certain cases, however it should be a go to strategy if you want your tests to be faster!

#4 Use :js => true only if you have to

Sometimes, your integration tests need to access an element that is set by JavaScript. To make it work you have to pass :js => true to your test. Note that passing :js => true forces your test to wait for all the JavaScript to be loaded, this can take a very long time and make your test really slow. Remove :js => true anywhere when you don’t need it and it will speed up your test suite!

#3   Use before(:each) hook wisely

Often when writing tests we tend to put a lot of stuff in before(:each) hook. The main issue with that is that before(:each) runs after every test where it is included. So if your before(:each) code is slow, it will slow down every single test. Solution to that would be to migrate some of the none repeatable code to before(:all) which runs once, or even better, refactor your code, so that it has less dependencies.

#2 Don’t let Capybara Wait for too long

There are 2 parts to this point.

Point 1: If you are using sleep() in your tests – you are doing something wrong.

By design in capybara expect() syntax waits for element to be loaded. You can even configure default wait time. When you say sleep(5), it means that it will wait 5 seconds no matter how fast page loads. Whereas if you use for example expect(page.find(…*).to syntax, it will wait for less then 5 seconds if it finds element faster. So please don’t use sleep!

Point 2:  Use Capybara has_no_* instead of RSpec negatives

This is something new to me, but I found it to be very productive. I first read about it in cool blog post by Nick Gauthier .

Essential if you have for example:

this code will wait until page has (or  for default wait time) an element “Dashboard”, which it never will, so it will be slow.

Whereas what you want to do is:

This code will look for “Dashboard” and quite if it doesn’t find it – which is much faster.

If you are curious about more of these things, I, once again, highly recommend to read this blog post.

#1 Decouple your code

Look at your code again and answer the following questions:

  • Can I extract parts of this code into a separate gem ?

If you answer yes – do it! Separate re-usable parts of your logic into a gem, test it thoroughly and save time, by not having to test it again in your test suite.

  • Can I extract logic into separate modules ?

Separating into modules gives you ability to test parts separately, this is faster! Also you can stub those modules whenever you don’t need to test them. Good example of separating into modules can be found here.

 

Have questions ? Ask them in comments! Want to see more cool stuff? Write your suggestions also in comments!

More amazing resources on the topic:

Hope this helps you to write speedy RSpecs!

Cheers,

Anatoly

Anatoly Spektor

IT Consultant with 6 years experience in Software Development and IT Leadership. Participated in such projects as Eclipse IDE, Big Blue Button, Toronto 2015 Panam Games.

Join the Discussion

Your email address will not be published. Required fields are marked *

arrow