My strategy to add tests to an application if you are on a budget

In the Ruby community there is the convention of adding tests whenever you do some changes to the code base. This is really awesome. Unfortunately it is not the same in other communities. In my experience doing technical due diligences of start ups this is a common weak point I usually find. Finally I must add that not all Rails code bases I have worked in where that good in terms of test coverage.

Let’s first see how many tests you should aim for having in your application and which kind of tests there are. After that I will show you my strategy to add tests to a poorly tested code base.

Speaking of lack of tests, How many tests should you have? A good practice is whenever you build a new feature you should add enough tests to cover the functionality’s requirements. You should be confident that the new code will work as expected. When fixing a bug a good practice is to add the necessary regression tests to ensure the bug never comes back. So if the amount of tests seems to be based on confidence and coverage… is that everything?

Which types of tests can you add?

This is not just a matter of the amount, but also of the types of tests you add. There are several types of tests you can add to your Rails application. Each type has its goal and coverage. You should choose wisely which kind of tests you add. Specially if you are on a tight budget. And just to be clear, by type of test I do not mean the things that you can write tests for in Rails, like models, mailers, controllers, etc. I mean a wider concept. That is: unit, request and integration tests, Let’s see them in detail.

Unit tests

This category of tests is used to test many concepts in Rails. You will typically use unit tests to test individual methods of models, helpers, mailers, controllers, etc.

The goal of unit tests is to test things in isolation. You will typically use these tests to check methods thoroughly. That includes inspecting all possible corner cases.

The coverage of this type of test is limited solely to the method it tests.

Request tests

This type of tests is used to check the requests that are sent to the application. The goal of request tests is to exercise the different endpoints of your web application, checking that the output they produce makes sense for a given input. The coverage of request tests is wider than in unit tests, but interactions with third party systems or mailing are mocked. That means that this type of test does not check the system as a whole.

Integration tests

Integration tests have the biggest coverage of all groups. Their goal is to check use cases resembling as much as possible the interaction that a real user would have with the system. That of course implies also interacting with third party systems.

My strategy to add tests to a poorly tested code base on a budget

Ideally I would advise you to have the biggest amount of tests and the highest possible test coverage, given of course that the tests you add make sense.. But what happens when you start working with a code base that almost has no tests? I have been in this situation in the past. From my experience I would advise you to follow these steps:

1. Start by writing the integration tests that cover the most important use cases for the business.
2. Once you have written those, you will be in a position in which you can make changes to the application while having the confidence that you will not break the most important workflows.
3. Once here, since integration tests are expensive, you can start writing unit and request tests that check scenarios not covered by integration tests until you have full coverage.
4. During this process ensure you add tests for the new functionality you create and also regression tests for every bug your fix!

And that was it for today’s post! If you enjoyed it, please do not forget to subscribe so that you do not miss any future updates. If you have any questions or want me to write about something in particular, please let me know in the comment section below!

See you in my next post! Adiós!