Open Collective
Open Collective
Loading

Rspec Tracer

COLLECTIVE
Open source

RSpec Tracer is a specs dependency analyzer, flaky tests detector, tests accelerator, and coverage reporter tool for Ruby projects

Contribute


Become a financial contributor.

Financial Contributions

Recurring contribution
Backer

Become a backer for $5.00 per month and support us

Starts at
$5 USD / month
Recurring contribution
Sponsor

Become a sponsor for $100.00 per month and support us

Starts at
$100 USD / month
Custom contribution
Donation
Make a custom one-time or recurring contribution.

Rspec Tracer is all of us

Our contributors 1

Thank you for supporting Rspec Tracer.

About


RSpec Tracer is a specs dependency analyzer, flaky tests detector, tests accelerator, and coverage reporter tool. It maintains a list of files for each test, enabling itself to skip tests in the subsequent runs if none of the dependent files are changed. It uses Ruby's built-in coverage library to keep track of the coverage for each test. For each test executed, the coverage diff provides the desired file list.
It's just not about reducing the time taken to run tests but also getting answers to questions that come before thinking about writing a single-line code. At times, we don't know which other components require testing because of the changes introduced. One possible way to have insights on this is to know which spec files would run some or all the tests when changing a specific source or spec file.

Since we know that a particular file is testing a specific component or feature, we get some idea of what else could change and whether it's desirable or not. We can also analyze the dependency amongst these components and retrospect the design choices made with this data. Indeed, this also comes in handy when we are refactoring the code-base. We can pick pieces with the least number of dependencies and avoid any surprises.

There is an option to run tests parallel and save time, but it runs all the tests. If we know for a fact that in the current state, a given set of tests needs run, why run the entire suite? Earlier, we talked about maintaining a map of files to spec files, but it is not helpful here. What we need is a map of the test to source and spec files. With this, we can check if any of the files changed or not. If not, no need to run this particular test.

Our team