Type: Feature Request
Status: Open (View Workflow)
Affects Version/s: None
Fix Version/s: 2.0.0.Beta1
Security Level: Public (Everyone can see)
Similar Issues:Show 10 results
ARQ-1664 Provide custom table filter for seeding and cleaning databases ARQ-1330 Allow mocking/spying on JSF base classes ARQ-906 Provide SPI for container configuration activation ARQ-946 Warp: Define SPI for custom server-side filters for alternative protocols ARQ-1690 Provide and API/SPI to solve backward compatibility ARQ-287 Add support for filtering tests based on required execution environment ARQ-387 Selenium extension should use the TestEnricher SPI to do injection into the test case ARQ-1691 Flexible model for browsers SPI ARQ-1082 Allow to provide external data sources on the SPI level. ARQ-950 Warp: define SPI for custom clent- or server-side filter/proxy
Provide an SPI (or observer hook) for filtering the test classes.
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
- security (whether running the test is allowed)
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) is handled in a few different ways:
- suite definition
- 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.