Abort-Mission is a lightweight Java library providing flexible test abortion support for test groups to allow fast failures.
- Provides a way to group your tests
- Lets you define certain pre-requisites for your tests
- Tracks how each group succeeds or fails
- Uses the collected data to prevent test runs which are predicted to fail already
If you are using Abort-Mission well, you don't need to wait for long CI runs when you know which tests will fail already because the DB became inaccessible or someone (not you) messed up... Saving time on CI and local test runs adds up in small increments not only saving money but reducing the time and resources used for build. This results in using less cloud runners, reducing electricity needs etc. by the end of the day we can help save the Planet too! Cool, right?
If you are still not convinced, you can trust the ancient proverb saying:
Tip
"Shoot for the Moon, and even if you miss, you can at least stop running your failing tests early."
Abort-Mission can be downloaded from a few Maven repositories. Please head to this page to find out more.
To find out which Abort-Mission dependency will you need, it is recommended to start with the booster created for the test framework you are using. Is your favorite framework missing? Let me know by creating an issue! No promises, but I will at least take a look.
- Mission Control
- Boosters
- Mission Report
- Strongback (All modules removed in 4.1.x)
- Strongback functionality is completely removed in 4.1.x release as Strongbacks were very slow and hard to maintain.
Abort-Mission views tests runs similarly to a space launch mission. Due to this, terminology mimics certain phases of a rocket launch. This section can help you understand what happens when.
Each test offers a slightly different situation, but the following list will cover all counters we will rely on when using Abort-Mission.
| Measurement point | What happens there? |
|---|---|
| Countdown failed | Test instance post processing failed |
| Countdown abort | Test instance post processing prevented |
| Countdown success | Test instance post processed successfully |
| Mission abort | Test start prevented / abort after start |
| Mission failed | Test failed |
| Mission success | Test executed successfully |
The oversimplified model used by this project relies on the following elements:
- A Mission Outline defining what Abort-Mission should do in which situation in scope of the Mission Context
- A number of Mission Health Check Matchers which allow the library to identify which category the test class belongs to
- A similar amount of Mission Health Check Evaluators which define thresholds for the decision-making
- A bunch of annotations to help with the configuration such as
- Defining which of the named Mission Contexts do we want to use
- Allowing suppression of abort decisions for certain tests
- Ignoring certain exceptions that are causing failures
From all of these, sooner or later you will need to have a Launch Sequence Template that will act as a controller which knows how your specific test framework needs to bind with the lifecycle stages we need to maintain. This is probably the hardest part to pull off, don't worry, if you are using a booster that was created for your test framework, it should be easy, the booster will do the heavy-lifting (after all that is the job of a booster).
Once you have these, you are probably fine.