What Are The Best Practices When Testing Rails Apps?

Today, your developers can write extremely sophisticated tests using Test-driven development style (TDD) and Behavioral-driven development style (BDD), along with making use of powerful test frameworks, using gems like RSpec and Cucumber. Rails by default comes with robust automated test capabilities, making it easy to write your tests. To begin with, I’d suggest adopting a test-driven development style if you’re new to this, otherwise, give behavioral-driven development approach a try. Secondly, remember it’s a lot easier to build a safeguard for your application while it's still in its initial stages and this will eventually lead to better quality, by enforcing good development practices down the road. On the other hand, if you’ve already built your Rails application and testing is the only thing standing between your application and your users, then with the right testing, you can put your doubts aside and debut it.

Even for the not particularly conscientious programmers who skip half the phases of the design methodology, writing code without testing is a foolhardy move. There are enough resources online to help you on your journey and rob you of any excuse of being new to testing. In spite of how simple it is to add automated testing to your Rails application, it’s an unpleasant surprise to discover how many projects exist were no tests are written or at best, very few, by the previous development team. The debate about how comprehensive testing should be will go on. Nevertheless, the need for at least, a basic automated testing is agreed upon and should exist for all applications.  

Ensuring there’s at least one high-level integration test written for every action in your controllers is a good rule to follow. In the future, this will provide developers a clear method of verifying the basic functionality of the application, to ensure it's working well when a developer decides to modify the code or upgrade a Rails version. Additionally, this approach provides future developers a clear picture of the entire collection of functionality provided by the application.

Different forms of testing

You’ll find three main types of tests in a typical Rails application, Model(Unit) tests, Controller tests, and View tests. Feature tests are also used where need be. These tests work as an end to end run-through test of your application. Each of these tests has a place in the testing world and could turn out to be equally important for you.

Model(Unit) Tests

Model or Unit specs are the simplest and quickest of the test types you will deal with in Rails. Here you are testing the normal CRUD(Create/Read/Update/Delete) operations on the model object. Additionally, they are fairly self-contained and can be used to test associations and validations.

Controller Tests

I’m sure you’ve come across the popular Rails philosophy, 'fat models skinny controllers.' Embrace this and make it your development goal to keep controllers free of avoidable logic and streamlined. While writing test cases for controllers, focus on checking three areas: controller response, returned data, and redirects versus renders. Specifically, check if the correct template is rendered. Your controller testing, essentially also includes testing Rails RESTful architecture as well as views.

Controllers are an integral part of your application since Rails is primarily a web development framework. Controller tests will form your backbone when it comes to testing all your conditional logic. With tests based on request type, user type, success or failure, of Models and so on. Owing to their use of the request/response cycle controller specs are a little bit slower than Model specs. Even so, they are still considerably faster than feature specs. When you need to test many paths through a controller, controller specs should be used over feature specs, as they are often easier to write and faster to run. This makes it a perfect place to do the bulk of your testing.

View Tests

View specs are often neglected by programmers, who instead choose to test all aspects of the visual representation in feature tests. Feature tests shouldn’t be used to test every last detail of a server rendered template. They are meant to give you a high-level behavior testing. Use view spec, whenever you need to test different markup based on some if statement or logic. View specs work well for testing in your templates, the conditional display of information. Using feature tests instead is the reason you end up with a long running test suite.  

Feature Tests

This is an excellent way to test your entire application or large parts of behavior at once from the user’s point of view. Feature specs are high-level tests which walk through your entire application ensuring each of the components work together. RSpec and Capybara allow you to write tests which can interact with the web page in this manner. However, feature tests run slower than all other types of tests. Therefore, it would be smart not to use feature tests to test every branch in your application. Use controller or other specs to test edge cases.

Testing Frameworks

RSpec

This Rails gem is a great starting point for testing Rails applications. The syntax focuses on readability and composability of tests. RSpec has various types of tests you can run to make sure your application is ready for its debut. First, you can run a Feature Specs test. These tests go through applications line by line to ensure all of the components work together. If your application passes this test, you can be assured of a positive user experience. You can move onto the Model Spec tests next. These tests divide applications up into small chunks. Each chunk is tested separately to make sure it works as it should. You can also use this tool to run Controller and View Spec tests. With all of these features, your application will be put through the ringer before it goes live.

Cucumber

Cucumber advocates the behavioral-driven development(BDD) style and supports execution on both browsers and in-memory. In spite of what its detractors would have you believe, Cucumber is not a pointless tool. A tool is only as useful as you make it. Cucumber is extremely valuable if you have an invested business team who want to see the value of your automated test suite or your domain is complicated enough for everyone, programmers included, and they would benefit from having things spelled out in layman's terms. Cucumber is more a collaboration framework, more than a testing framework. If you don't collaborate with the business team and programmers, then cucumber will prove useless. Then again, ideally you should be collaborating. Once you start with Cucumber, you’ll discover it offers you behavior-driven development at its finest and easiest. It runs automated tests so you can make sure your applications are up to the mark. You start by figuring out the behavior you’ve come to expect when people interact with your application. Then you can use those examples to run acceptance tests. Cucumber will identify which of your goals you are meeting and which examples are not working out. Then it compiles a document including the specifications and the tests. This makes it easy for your team to fix the problems and move forward.

Minitest

Minitest is the default testing framework included in the latest version of Rails. The official Rails Guide To Testing is another good book to guide you through Minitest. Minitest is also a good place to start.  Start with going through all your models and making tests for everything, all your scopes,  all your public instance, all your validations, and class methods. Now don't let go of your momentum to catch up with the massive pile of test debt you've accumulated. As you keep moving forward, make sure to catch up and each week, put in a few test debt stories into your sprints. Ensure you have tests for it, whenever you touch new code. Don’t touch integration tests until you have your models well tested.

Conclusion:

 Personal preference will play a huge role in choosing many aspects of a Rails application. Testing is no exception. Testing should be an integral part of your web development process. If you run proper tests, you will be putting your best foot forward every time you publish an application. While we could spend days debating over which testing framework to use, they all have their merits. The most important thing is you are testing. And a word of advice; be pragmatic about it, not dogmatic.