Just think, rule-based test filtering. ARQ-905
Users of Arquillian would really benefit from having an extensible test filtering mechanism, something that JUnit and TestNG just aren't giving them today.
This feature could be provided as an SPI (or observer hook) for deciding whether a test class (or even method) should be executed.
There are many reasons to filter which tests are run:
- execution speed
- available environment (e.g., based on target container, based on access to shared resource)*
- permitted exclusions (like in a TCK)
- user story
- deliverable
- demo
- security (whether running the test is allowed)
- ...
* See ARQ-287 Add support for filtering tests based on required execution environment
We can't think of all of them. That's why we should over an SPI to allow these possibilities to be explored.
Currently, test filtering (or selection) can be handled in a couple different ways:
- suite definition
- groups
- test plugin includes/excludes (e.g., Maven surefire)
While these options can handle many of the cases, they are still very limiting, esp since they are static declarations. Imagine long lists of test classes or brow-wrinkling include/exclude logic.
Let's give the developers the choice of how they want to implement filtering. We can then provide some nice options in the way of extensions. For instance, imagine a rule-based test filter extension. You can write rules in the Drools DSL to decide which tests to execute. This is very powerful for user story-based development and even contract deliverables.
The filter should be able to inject various parts of the Arquillian runtime, including:
- Current test class being processed
- Active container class and configuration
- Test archive
The filter should be able to invoke an "ignore" or "skip" method to instruct Arquillian to skip running the test.
Thoughts?
