smart-testing
smart-testing copied to clipboard
arquillian
Add custom resolution in affected strategy
Currently affected strategy just creates a graph between tests and imports of these tests. Then with any change on a Java class (business class) it checks on the graph which tests imports this class and adds this test in the list of tests to be executed.
But currently does not offer support to any other kind. The idea would be to create a file (with some defaults and user could set its own) where you set how to resolve special cases, for example, modification of persistence.xml means execute tests that imports (or its business classes imports) EntityManager, EntityManagerFactory, ....
Apart from that module should provide also an SPI to make thing even more advanced resolutions, for example if you modify pom.xml you get the artifact that has been updated, find where classes of this artifact are used and finally get the tests where these classes are used.
Notice that first approach is for static resources meanwhile the second one is for dynamic resolution.
Apart from that module should provide also an SPI to make thing even more complex
This sentence is a bit disturbing :)
Overall I've been also thinking about supporting property changes and external libraries, but let's first focus on "local code". I'm not sure if "creating file where you define special cases" would be the most appropriate one, so let's use this issue to discuss it.
Well my idea is to provide two things, the first one is that file, just for simple cases might work and it is easy to implement.
In second phase or at the same time, then create an SPI to create more complex resolutions, like the one of scanning changes on pom.xml
Not sure if new SPI is really needed - as we already have one we can use - TestExecutionPlanner - can't we use this one in the same fashion as we do SCM-based decisions now?
Well my idea is that the final users can even provide their own resolutions.
About using TestExecutionPlanner well it is not about creating a new strategy, it is just a translation that happens on affected strategy between a modification and imports required because of this modification.
Well my idea is that the final users can even provide their own resolutions.
That's clear, as we are discussing SPI.
About using
TestExecutionPlannerwell it is not about creating a new strategy, it is just a translation that happens on affected strategy between a modification and imports required because of this modification.
To great extent it is, the question is more how we want to structure it. Do we want to have one SPI which we can compose together as one concept (e.g. several impl of TestExecutionPlanner taking care of different aspects such as production to test mapping, configuration to tests mapping etc - which is all understood as "affected") or have it composed within TestExecutionPlanner itself as an "sub-SPI".
But this is something we can think about later on. First I believe it's important to define other use-cases we would like to support and then think about the implementation side of it.
@lordofthejars can you break it down to tasks if we feel like it is ready for it?
My idea was not to create a separate TestExecutionPlanner but create some kind of chain that is executed and transforms the files (.xml, .json, ...) into .java files, so these Java files then are used to get test dependencies. As first approach I would say that this chain is coded using chain of responsibility pattern and as first approach be hardcoded. Since at the very beginning we will have just some few supports then it is fine. After that when we have configuration files, we could create a new issue to be implemented which allows you to append/create chains from yaml configuration file.
WDYT?
PS: After this discussion I will create the tasks required to implement it.