Rspec Tracer
COLLECTIVE
Open source
RSpec Tracer is a specs dependency analyzer, flaky tests detector, tests accelerator, and coverage reporter tool for Ruby projects
Contributors
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.
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
Abhimanyu Singh
Admin