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:
* 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:
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:
The filter should be able to invoke an "ignore" or "skip" method to instruct Arquillian to skip running the test.
Also killer feature would be to automatically decide which tests should actually be run based on code changes - similar to JUnitMax / Inifitest (I like to call it reversed code coverage). Maybe we can resurrect SibillaTest
|Retrieving data ...|