README.md in rspec-tracer-0.5.0 vs README.md in rspec-tracer-0.6.0
- old
+ new
@@ -6,39 +6,46 @@
It uses [Ruby's built-in coverage library](https://ruby-doc.org/stdlib/libdoc/coverage/rdoc/Coverage.html)
to keep track of the coverage for each test. For each test executed, the coverage
diff provides the desired file list. RSpec Tracer takes care of reporting the
**correct code coverage when skipping tests** by using the cached reports. Also,
-note that it will **never skip any tests which failed or were pending** in the last runs.
+note that it will **never skip**:
+- **Flaky examples**
+- **Failed examples**
+- **Pending examples**
+
Knowing the examples and files dependency gives us a better insight into the codebase,
and we have **a clear idea of what to test for when making any changes**. With this data,
we can also analyze the coupling between different components and much more.
## Note
-You should take some time and go through the [document](./RSPEC_TRACER.md) describing
-the **intention** and implementation details of **skipping tests**, **managing coverage**,
-and **caching on CI**, etc.
+You should take some time and go through the **[document](./RSPEC_TRACER.md)** describing
+the **intention** and implementation details of **managing dependency**, **managing flaky tests**,
+**skipping tests**, and **caching on CI**. You must go through the README file before
+integrating the gem into your project to better understand what is happening.
## Table of Contents
* [Demo](#demo)
* [Installation](#installation)
* [Compatibility](#compatibility)
* [Additional Tools](#additional-tools)
* [Getting Started](#getting-started)
* [Environment Variables](#environment-variables)
+ * [BUNDLE_PATH](#bundle_path)
* [CI](#ci)
* [LOCAL_AWS](#local_aws)
* [RSPEC_TRACER_NO_SKIP](#rspec_tracer_no_skip)
* [RSPEC_TRACER_S3_URI](#rspec_tracer_s3_uri)
* [RSPEC_TRACER_UPLOAD_LOCAL_CACHE](#rspec_tracer_upload_local_cache)
* [TEST_SUITES](#test_suites)
* [TEST_SUITE_ID](#test_suite_id)
* [Sample Reports](#sample-reports)
* [Examples](#examples)
+ * [Flaky Examples](#flaky-examples)
* [Examples Dependency](#examples-dependency)
* [Files Dependency](#files-dependency)
* [Configuring RSpec Tracer](#configuring-rspec-tracer)
* [Filters](#filters)
* [Defining Custom Filteres](#defining-custom-filteres)
@@ -140,12 +147,20 @@
6. After running your tests, open `rspec_tracer_report/index.html` in the
browser of your choice.
## Environment Variables
-To get better control on execution, you can use the following two environment variables:
+To get better control on execution, you can use the following environment variables
+whenever required.
+### BUNDLE_PATH
+
+Since the bundler uses a vendor directory inside the project, it might cause slowness
+depending on the vendor size. You can configure the bundle path outside of the project
+using `BUNDLE_PATH` environment variable, for example, `BUNDLE_PATH=$HOME/vendor/bundle`.
+Make sure to cache this directory in the CI configuration.
+
### CI
Mostly all the CI have `CI=true`. If not, you should explicitly set it to `true`.
### LOCAL_AWS
@@ -188,11 +203,11 @@
### TEST_SUITE_ID
If you have a large set of tests to run, it is recommended to run them in
separate groups. This way, RSpec Tracer is not overwhelmed with loading massive
-cached data in the memory. Also, it generate and use cache for specific test suites
+cached data in the memory. Also, it generates and uses cache for specific test suites
and not merge them.
```ruby
TEST_SUITE_ID=1 bundle exec rspec spec/models
TEST_SUITE_ID=2 bundle exec rspec spec/helpers
@@ -226,9 +241,22 @@
**Next Run**
+
+### Flaky Examples
+
+These reports provide flaky tests information. Assuming **the following two tests
+failed in the first run.**
+
+**Next Run**
+
+
+
+**Another Run**
+
+
### Examples Dependency
These reports show a list of dependent files for each test.