feat(#114): implements configuration file per module. #262

dipak-pawar · 2017-11-15T13:08:48Z

Changes proposed in this pull request:

Supporting configuration file per module
Introduced inherit parameter in configuration file.
Updated documentation
Adds ftest in test-bed for multi-module project.

parent
 - config
   - smart-testing.yml 
   - api
   - impl-base
   - spi
     - smart-testing.yml
 - container
    - api
    - impl-base
 - smart-testing.yml

Configuration file selection for the above example will be as follows:

config/api - parent/config/smart-testing.yml
config/impl-base - parent/config/smart-testing.yml
config/spi - parent/config/spi/smart-testing.yml
container/api - parent/smart-testing.yml
container/impl-base - parent/smart-testing.yml

Fixes #114

bartoszmajsak · 2017-11-21T12:39:01Z

core/src/main/java/org/arquillian/smart/testing/configuration/ConfigurationLoader.java

+    static Map<String, Object> getConfigParametersFromFile(Path filePath) {
+        if (!filePath.toFile().exists()) {
+            logger.warn(String.format("The configuration file %s is not exists.", filePath));
+            return new HashMap<>(0);


Are we mutating this map afterward?

no we are not mutating this map afterwords

Then maybe .emptyMap() would be better so we actually prevent from mutating it in the caller anyway (at least what is in the map, not the content itself)

bartoszmajsak · 2017-11-21T12:45:52Z

core/src/main/java/org/arquillian/smart/testing/configuration/ConfigurationLoader.java

        Map<String, Object> yamlConfiguration = readConfiguration(configFile);
-        return parseConfiguration(yamlConfiguration);
+        final Configuration configuration = parseConfiguration(yamlConfiguration);
+        final ObjectMapper objectMapper = new ObjectMapper();


This can be a constant I believe

We are using it only once in ConfigurationLoader. I am not sure why do we really need to declare it as constant?

I misinterpreted it with Jackson object mapper object at first, so probably not. OTOH I don't feel like having mapToObject method with now a constructor and a call to readValue is really needed.

bartoszmajsak · 2017-11-21T12:52:33Z

core/src/main/java/org/arquillian/smart/testing/configuration/ConfigurationLoader.java

-        } catch (IOException e) {
-            throw new UncheckedIOException(e);
-        }
+        return readParseOverWriteConfiguration(path.toFile());


This method name makes me a bit concerned as we are doing 3 things at once. But also shows that this class as such is doing the same (3 responsibilities). Can you try to figure out how to clean it?

bartoszmajsak · 2017-11-21T12:56:09Z

.../java/org/arquillian/smart/testing/configuration/ConfigurationOverWriteUsingInheretTest.java

+import static org.arquillian.smart.testing.configuration.ConfigurationLoader.SMART_TESTING_YML;
+import static org.assertj.core.api.Assertions.assertThat;
+
+public class ConfigurationOverWriteUsingInheretTest {


bartoszmajsak · 2017-11-21T12:56:32Z

...an/smart/testing/configuration/ConfigurationOverWriteUsingInheretWithSystemPropertyTest.java

+import static org.assertj.core.api.Assertions.assertThat;
+
+@Category(NotThreadSafe.class)
+public class ConfigurationOverWriteUsingInheretWithSystemPropertyTest {


bartoszmajsak · 2017-11-21T21:00:51Z

...ed/src/main/java/org/arquillian/smart/testing/ftest/testbed/project/ProjectConfigurator.java

@@ -63,16 +62,19 @@ public ProjectConfigurator withConfiguration(Configuration configuration) {
        return this;
    }

-    public ProjectConfigurator createConfigFile() {
+    public ProjectConfigurator withConfigFile() {


What is the reason behind this rename?

bartoszmajsak · 2017-11-21T21:02:08Z

...ava/org/arquillian/smart/testing/ftest/configurationfile/ConfigurationFilePerModuleTest.java

+                .withConfiguration(newConfiguration)
+                    .withConfigFileIn("config/impl-base")
+                .withConfiguration(changedConfiguration)
+                    .withConfigFileIn("junit/core")


This chain is a bit hard for me to follow. Can you explain what is the desired flow of action here? I think with... makes it a bit blurry to follow as not everything should be prefixed like that.

bartoszmajsak · 2017-11-21T21:11:34Z

...xtension/src/main/java/org/arquillian/smart/testing/mvn/ext/SmartTestingMavenConfigurer.java

            }
-        });
+        }


My proposal for refactoring:

private void configureExtension(MavenSession session, Configuration configuration) { final Consumer<MavenProject> configureSmartTestingExtensionAction; if (hasModuleSpecificConfigurations(session)) { configureSmartTestingExtensionAction = applyModuleSpecificConfiguration(configuration); } else { final MavenProjectConfigurator mavenProjectConfigurator = new MavenProjectConfigurator(configuration); configureSmartTestingExtensionAction = mavenProject -> configureMavenProject(mavenProjectConfigurator, mavenProject, configuration); } session.getAllProjects().forEach(configureSmartTestingExtensionAction); } private boolean hasModuleSpecificConfigurations(MavenSession session) { final ConfigLookup lookUp = new ConfigLookup(session.getExecutionRootDirectory()); final boolean moreThanOneConfigFile = lookUp.hasMoreThanOneConfigFile(SMART_TESTING_YML, SMART_TESTING_YAML); return moreThanOneConfigFile && System.getProperty(SMART_TESTING_CONFIG) == null; } private Consumer<MavenProject> applyModuleSpecificConfiguration(Configuration configuration) { return mavenProject -> { final ConfigLookup configLookup = new ConfigLookup(mavenProject.getBasedir().toString()); final File dirWithConfig = configLookup.getFirstDirWithConfigOrProjectRootDir(); final Configuration mavenProjectConfiguration = configLookup.isConfigFromProjectRootDir() ? configuration : ConfigurationLoader.load(dirWithConfig); if (mavenProjectConfiguration.isDisable()) { logExtensionDisableReason(logger, SMART_TESTING_DISABLE + " is set for module " + mavenProject.getArtifactId()); return; } if (mavenProjectConfiguration.areStrategiesDefined()) { final MavenProjectConfigurator mavenProjectConfigurator = new MavenProjectConfigurator(mavenProjectConfiguration); configureMavenProject(mavenProjectConfigurator, mavenProject, mavenProjectConfiguration); } else { logger.warn( "Smart Testing Extension is installed but no strategies are provided for %s module. It won't influence the way how your tests are executed. " + "For details on how to configure it head over to http://bit.ly/st-config", mavenProject.getArtifactId()); } }; }

To be honest, it took me some time to understand the code. as for assigning the consumer function to the local variable - I would use it only when the method returns some value. In this case I would use this:

private void configureExtension(MavenSession session, Configuration configuration) { final File executionRootDirectory = new File(session.getExecutionRootDirectory()); List<MavenProject> allProjects = session.getAllProjects(); if (hasModuleSpecificConfigurations(executionRootDirectory, this::isProjectRootDirectory)) { allProjects.forEach(mavenProject -> applyModuleSpecificConfiguration(configuration, mavenProject)); } else { final MavenProjectConfigurator mavenProjectConfigurator = new MavenProjectConfigurator(configuration); allProjects.forEach(mavenProject -> configureMavenProject(mavenProjectConfigurator, mavenProject, configuration)); } } private void applyModuleSpecificConfiguration(Configuration configuration, MavenProject mavenProject) { final ConfigLookup configLookup = new ConfigLookup(mavenProject.getBasedir(), this::isProjectRootDirectory); final File dirWithConfig = configLookup.getFirstDirWithConfigOrWithStopCondition(); final Configuration mavenProjectConfiguration = configLookup.isConfigFromProjectRootDir() ? configuration : ConfigurationLoader.load(dirWithConfig); if (mavenProjectConfiguration.isDisable()) { logExtensionDisableReason(logger, SMART_TESTING_DISABLE + " is set for module " + mavenProject.getArtifactId()); return; } if (mavenProjectConfiguration.areStrategiesDefined()) { final MavenProjectConfigurator mavenProjectConfigurator = new MavenProjectConfigurator(mavenProjectConfiguration); configureMavenProject(mavenProjectConfigurator, mavenProject, mavenProjectConfiguration); } else { logger.warn( "Smart Testing Extension is installed but no strategies are provided for %s module. It won't influence the way how your tests are executed. " + "For details on how to configure it head over to http://bit.ly/st-config", mavenProject.getArtifactId()); } }

Just my opinion ;-)

bartoszmajsak · 2017-11-21T21:15:59Z

docs/configfile.adoc

+=== Configuration File per Maven Module:
+You can define configuration file per maven module. However it's not mandatory to define configuration per each module.
+
+NOTE: Whenever you are using configuration file per maven module, make sure to define strategies & scm properties


Are scm properties really required? Why should they be?

Yes, it needs to be define in parent config file OR define it using system properties. Because we are loading scm changes by looking into parent configuration file.

Otherwise ST couldn't find required changes between commit ranges. as it will take default range which is HEAD-HEAD~0

So it is not required but needed if you use it. Maybe we could clarify this sentence then.

bartoszmajsak · 2017-11-21T21:41:00Z

docs/configfile.adoc

+* config/impl-base - parent/config/smart-testing.yml
+* config/spi - parent/config/spi/smart-testing.yml
+* container/api - parent/smart-testing.yml
+* container/impl-base - parent/smart-testing.yml


What do you think about having concrete file content listed and then used as an example to show effective resolution instead?

…into issue_114

bartoszmajsak

Thanks for the improvements @dipak-pawar - two small suggestions from my side. WDYT?

bartoszmajsak · 2017-11-28T09:13:18Z

core/src/test/java/org/arquillian/smart/testing/configuration/ConfigurationFileBuilder.java

        properties = new HashMap<>();
    }

-    static ConfigurationFile SmartTestingConfigurationFile() {
-        return new ConfigurationFile();
+    static ConfigurationFileBuilder SmartTestingConfigurationFile() {


Uppercase in method name is a bit unusual for Java coders unless it's a constructor. Can we rename it to simple configurationFile? Also create could be writeTo, so it could be written as

configurationFile() .mode("ordering") .applyTo("surefire") .inherit(Paths.get(root, SMART_TESTING_YAML).toString()) .writeTo(Paths.get(root, SMART_TESTING_YML));

bartoszmajsak · 2017-11-28T09:36:21Z

core/src/main/java/org/arquillian/smart/testing/configuration/ConfigurationReader.java

+            filePath = filePath.getParent().resolve(inherit);
+            config = getConfigParametersFromFile(filePath);
+            if (!config.isEmpty()) {
+                configs.add(0, config);


Alternatively, you can use Deque as a Stack - might make it a bit easier to understand what we really do with inheritance.

MatousJobanek · 2017-11-28T10:13:51Z

core/src/main/java/org/arquillian/smart/testing/configuration/Configuration.java

        configItems.add(new ConfigurationItem("debug", SMART_TESTING_DEBUG, false));
        configItems.add(new ConfigurationItem("autocorrect", SMART_TESTING_AUTOCORRECT, false));
        configItems.add(new ConfigurationItem("customStrategies", SMART_TESTING_CUSTOM_STRATEGIES_PATTERN));
+        configItems.add(new ConfigurationItem(INHERIT, null));


Do we need to register the inherit parameter? We don't use it anywhere (the getter), do we?
So do we need to have the inherit field in the class at all?

MatousJobanek · 2017-11-28T10:18:36Z

core/src/main/java/org/arquillian/smart/testing/configuration/ConfigLookup.java

+        }
+
+        return count > 1;
+    }


Personally, I would move the three methods outside of this class - they are not related to the stopCondition and are Maven-extension specific.

MatousJobanek · 2017-11-28T10:35:50Z

core/src/main/java/org/arquillian/smart/testing/configuration/ConfigurationLoader.java

+        ConfigurationReader configurationReader = new ConfigurationReader();
+        final Map<String, Object> effectiveConfig = configurationReader.readConfiguration(configFile);
+
+        return ConfigurationLoader.loadAsConfiguration(effectiveConfig);


as you are in the same class, you can call the method directly.

MatousJobanek · 2017-11-28T10:39:03Z

core/src/main/java/org/arquillian/smart/testing/configuration/ConfigurationLoader.java

+
+    private static Configuration loadEffectiveConfiguration(File configFile) {
+        ConfigurationReader configurationReader = new ConfigurationReader();
+        final Map<String, Object> effectiveConfig = configurationReader.readConfiguration(configFile);


if you call this method loadEffectiveConfiguration then the method returning the final Map should have a similar name, eg: readEffectiveConfiguration - to make it transparent which part of the code handles the inheritance.

MatousJobanek · 2017-11-28T10:44:20Z

core/src/main/java/org/arquillian/smart/testing/configuration/ObjectMapper.java

 import java.util.List;
 import java.util.Map;
 import java.util.Optional;
 import java.util.stream.Collectors;

 class ObjectMapper {

-    static <T extends ConfigurationSection> T mapToObject(Class<T> aClass, Map<String, Object> map) {
+    <T extends ConfigurationSection> T readValue(Class<T> aClass, Map<String, Object> map) {


Is there any reason for making it non-static? For me, this change is not necessary and the new usage doesn't bring any benefit - it is just longer - eg. see here:

- final Configuration configuration = mapToObject(Configuration.class, yamlConfiguration); + final ObjectMapper objectMapper = new ObjectMapper(); + final Configuration configuration = objectMapper.readValue(Configuration.class, yamlConfiguration);

And also this usage: https://github.com/arquillian/smart-testing/pull/262/files#diff-4b3896eea6384f8873440fb7836cbfa0R31

I am fine with it. But as @bartoszmajsak suggested me #262 (comment) & also we have a discussion about the same in mattermost.

My comment was about object mapper variable in that method, not really about the method itself being static.

ok then I will make it static.

MatousJobanek · 2017-11-28T12:14:51Z

...ava/org/arquillian/smart/testing/ftest/configurationfile/ConfigurationFilePerModuleTest.java

+        final Collection<TestResult> expectedTestResults = project
+            .applyAsLocalChanges("Adds new unit test");
+
+        expectedTestResults.addAll(project.applyAsCommits("Deletes one test", "Renames unit test"));


Having this set of commits with the given configuration won't verify that the correct configuration is used.
configuration in parent dir has selecting (default) mode and new, changed strategies
for config/impl-base with the strategy new and mode selecting and you use Adds new unit test commit, which means that even if the parent configuration is read, then the test will pass - always run only the new test.
Similarly, for the junit/core module.
you can verify it removing the lines 53-56

yes this way we can make sure that configuration file applied correctly.

MatousJobanek · 2017-11-28T12:17:57Z

...xtension/src/main/java/org/arquillian/smart/testing/mvn/ext/SmartTestingMavenConfigurer.java

+        return mavenProject -> {
+            final ConfigLookup configLookup = new ConfigLookup(mavenProject.getBasedir(), this::isProjectRootDirectory);
+            final File dirWithConfig = configLookup.getFirstDirWithConfigOrWithStopCondition();
+            final Configuration mavenProjectConfiguration = configLookup.isConfigFromProjectRootDir() ? configuration :


On the previous line, you call configLookup.getFirstDirWithConfigOrWithStopCondition() and here using the method configLookup.isConfigFromProjectRootDir() you call the same method again: getFirstDirWithConfigOrWithStopCondition()
To be honest, this is very cryptic to my taste.

I'm asking myself, is it really worth having this complicated check there? When looking at the code, it doesn't seem to be an optimization at all - this solution is maybe more time and resource consuming.

ok let me see how can we make it more readable & less complicated

MatousJobanek · 2017-11-28T12:21:02Z

...xtension/src/main/java/org/arquillian/smart/testing/mvn/ext/SmartTestingMavenConfigurer.java

+                ConfigurationLoader.load(dirWithConfig);
+            if (mavenProjectConfiguration.isDisable()) {
+                logExtensionDisableReason(logger,
+                    SMART_TESTING_DISABLE + " is set for module " + mavenProject.getArtifactId());


Please, use the similar message as it is used here: https://github.com/arquillian/smart-testing/blob/master/mvn-extension/src/main/java/org/arquillian/smart/testing/mvn/ext/MavenProjectConfigurator.java#L67

MatousJobanek · 2017-11-28T12:25:28Z

...xtension/src/main/java/org/arquillian/smart/testing/mvn/ext/SmartTestingMavenConfigurer.java

+                    "Smart Testing Extension is installed but no strategies are provided for %s module. It won't influence the way how your tests are executed. "
+                        + "For details on how to configure it head over to http://bit.ly/st-config",
+                    mavenProject.getArtifactId());
+            }


maybe, it would be good to have the checks (if the ST should be installed for the module) in separated class.
As it is done for SkipInstallationChecker as well as for SkipModuleChecker

I think we are just checking configuration.isDisable() to check to ST should be installed for module. So I don't think we should move it to separated class.

You check two things here:
mavenProjectConfiguration.isDisable()
and
mavenProjectConfiguration.areStrategiesDefined()

MatousJobanek · 2017-11-28T12:26:57Z

...xtension/src/main/java/org/arquillian/smart/testing/mvn/ext/SmartTestingMavenConfigurer.java

-        });
+            if (mavenProjectConfiguration.areStrategiesDefined()) {
+                final MavenProjectConfigurator mavenProjectConfigurator =
+                    new MavenProjectConfigurator(mavenProjectConfiguration);


the instantiation of this class can be inside of the configureMavenProject method - you pass the configuration instance there anyway

* add configurationchecker & moduleSTInstallationChecker

MatousJobanek · 2017-12-04T13:06:13Z

core/src/main/java/org/arquillian/smart/testing/configuration/ObjectMapper.java

+        return objectMapper.readValue(aClass, map);
+    }
+
+    <T extends ConfigurationSection> T readValue(Class<T> aClass, Map<String, Object> map) {


Is this necessary? What is the benefit of it?

it's not necessary. But I created it to keep it clean. With mapToObject we have static factory method due to which you don't have to create ObjectMapper instance each time.

With mapToObject we have static factory method due to which you don't have to create ObjectMapper instance each time.

if it is a static method, then you don't create any instance of the class.
This approach is wrongly used in several cases in the ST code - instead of using classes such as ConfigurationChecker and ConfigurationReader where you need to create an instance of them and then call one method (without any need to keep the state) you can use them as static "util" classes.

MatousJobanek · 2017-12-04T13:21:02Z

core/src/main/java/org/arquillian/smart/testing/configuration/ConfigurationReader.java

+        for (String key: inner.keySet()) {
+            if (!Map.class.isAssignableFrom(inner.get(key).getClass()) || !effective.containsKey(key)){
+                effective.put(key, inner.get(key));
+                continue;


my opinion: instead of continue I would use the whole if-else statement.

MatousJobanek · 2017-12-04T13:25:40Z

core/src/main/java/org/arquillian/smart/testing/configuration/ConfigurationReader.java

+
+    private Map<String, Object> overwriteInnerProperties(Map<String, Object> effective, Map<String, Object> inner) {
+        for (String key: inner.keySet()) {
+            if (!Map.class.isAssignableFrom(inner.get(key).getClass()) || !effective.containsKey(key)){


is it possible to move this check to some separated method with a name expressing what the if does?
something like: isTrivialPropertyOrNotContainedInMap
or maybe do it the other way around - isNonTrivialPropertyContainedInMap

MatousJobanek · 2017-12-04T13:26:54Z

core/src/main/java/org/arquillian/smart/testing/configuration/ConfigurationReader.java

+
+        Map<String, Object> effectiveConfig = configs.pollFirst();
+        while (!configs.isEmpty()) {
+            effectiveConfig = overwriteInnerProperties(effectiveConfig, configs.pollFirst());


There is no need to assign the returned value to the variable - the instance of effectiveConfig is modified directly.

MatousJobanek · 2017-12-04T13:37:46Z

...quillian/smart/testing/ftest/configurationfile/ConfigurationFilePerModuleFunctionalTest.java

+    public final TestBed testBed = new TestBed(GIT_CLONE);
+
+    @Test
+    public void should_load_configuration_from_modules_config_file_for_local_changes_where_parent_config_file_has_only_strategies_defined() {


my opinion: can be the name a bit shorter? eg:
should_load_config_from_module_config_file_for_local_changes_instead_of_parent_one
similarly for the following one.

btw, what is the difference between these two tests? Both of them verify if the module related config file is taken, right?

yes, there is difference, in one test - parent config having only strategy defined. & in another parent config having scm & strategy defined which is already mentioned in method name

is it possible to merge it into one test?

ok I will merge it into one.

MatousJobanek · 2017-12-04T15:00:03Z

docs/configfile.adoc

+If config file doesn't contain `inherit` parameter. Then Smart Testing won't inherit any configuration properties.
+
+=== Configuration File per Maven Module:
+You can define configuration file per maven module. However it's not mandatory to define configuration per each module.


this is not necessary I think - it describes the same as on the line 39

I think it's good to have it.

Smart Testing is looking in each module's root dir for configuration file. If it didn't find config file there, it'll look recursively for the first config file in the parent dir containing pom.xml.

has the very same meaning as

You can define configuration file per maven module. However, it's not mandatory to define configuration per each module.

both of them says that you can define the config file in maven the module (or in parent dirs) and if it's not there (which means that it is not mandatory) it will look recursively for the first config file

MatousJobanek · 2017-12-04T15:01:23Z

docs/configfile.adoc

+You can define configuration file per maven module. However it's not mandatory to define configuration per each module.
+
+NOTE: Whenever you are using configuration file per maven module, make sure to define strategies in project's
+parent configuration file or using system property. If you are running tests against range of commits, you need to define scm properties in project's parent config file or using system property.


Whenever you are using configuration file per maven module, make sure to define strategies in project's parent configuration file or using system property

This is very confusing - it can be specified also inside of the module config file. I would remove it.

no you can't specify it inside module config file. You have to define it in project's parent config file or using system property. Otherwise Smart testing will load parent configuration having no strategy defined which will disable ST having reason no strategy defined at least in case of mvn extension

This is the same case of scm properties as well

Then describe it in this way as you just did in your comment.

This also brings a good point - that you can use at these places your ModuleSTInstallationChecker logic

MatousJobanek · 2017-12-04T15:59:38Z

docs/configfile.adoc

+ - smart-testing.yml #<!--3-->
+```
+
+<1>


these numbers are not correctly formatted

you mean numbers mentioned in xml config file

I mean the numbers <1> in the resulting documentation page

MatousJobanek · 2017-12-04T16:00:50Z

docs/configfile.adoc

+----
+
+<2>
+parent/config/spi/smart-testing.yml


in the other cases, there is a dot at the beginning. not here. is it intentional?

no I missed it here. thanks for catching it up.

MatousJobanek · 2017-12-04T16:03:20Z

docs/configfile.adoc

@@ -43,6 +108,9 @@ NOTE: You can use either a `.yml` or `.yaml` extension for this file.
 |===
 |Field | Description

+a| inherit
+a| This is used to define absolute or relative path for configuration file from where you want to overwrite paremeters not defined in current config file.


you don't overwrite parameters that are not defined - there is nothing to overwrite ;-)
I think that enough is saying:
This is used to define absolute or relative path to parent configuration file

MatousJobanek · 2017-12-04T16:07:55Z

docs/configfile.adoc

+
+NOTE: Whenever you are using configuration file per maven module, make sure to define strategies in project's
+parent configuration file or using system property. If you are running tests against range of commits, you need to define scm properties in project's parent config file or using system property.
+It won't work if you define scm properties in any module's config file and not in parent config file.


Please, create an issue for it.

created #274

* code refactoring

…into issue_114

dipak-pawar · 2017-12-07T11:54:32Z

@bartoszmajsak , @MatousJobanek Can you have a look into it?

MatousJobanek

Just one small thing, otherwise, I'm good with it. Good job @dipak-pawar

MatousJobanek · 2017-12-11T06:29:31Z

...on/src/main/java/org/arquillian/smart/testing/mvn/ext/checker/SkipSTInstallationChecker.java

+
+import static org.arquillian.smart.testing.configuration.Configuration.SMART_TESTING_DISABLE;
+
+public class SkipSTInstallationChecker {


This class name is very similar to: SkipInstallationChecker it's very confusing.
Please, merge these two classes. The constructor can stay same, you just add another method shouldSkipForConfig(Configuration config) which you will call at the places where you call your SkipSTInstallationChecker

bartoszmajsak · 2017-12-12T23:20:57Z

@dipak-pawar thanks for your work! Please take care of the merge conflict and merge. Just clean up extended commit message as we don't need a log of all intermediate commits :)

…into issue_114

feat(arquillian#114): Implement configuration file per module.

eea8c8c

dipak-pawar requested review from MatousJobanek and bartoszmajsak November 15, 2017 13:08

bartoszmajsak requested changes Nov 21, 2017

View reviewed changes

dipak-pawar added 4 commits November 22, 2017 19:44

Adds changes as per review

1c7d848

Merge branch 'master' of https://github.com/arquillian/smart-testing …

a201245

…into issue_114

Merge branch 'master' of https://github.com/arquillian/smart-testing …

bf8964b

…into issue_114

Implemented map level inheritance

220e383

dipak-pawar force-pushed the issue_114 branch from c5de695 to 220e383 Compare November 24, 2017 10:27

bartoszmajsak reviewed Nov 28, 2017

View reviewed changes

dipak-pawar added 2 commits November 28, 2017 16:31

use Deque for implentation

09cf3c8

Rename method def in config file builder

3dd67de

MatousJobanek requested changes Nov 28, 2017

View reviewed changes

dipak-pawar force-pushed the issue_114 branch from c39625a to 1dc8ba9 Compare November 30, 2017 08:39

Adds changes as per review

24d40e5

dipak-pawar force-pushed the issue_114 branch from 1dc8ba9 to 24d40e5 Compare November 30, 2017 08:42

* overwrite inner properties

a12c724

* add configurationchecker & moduleSTInstallationChecker

dipak-pawar force-pushed the issue_114 branch from cdfe626 to a12c724 Compare December 1, 2017 05:53

MatousJobanek requested changes Dec 4, 2017

View reviewed changes

MatousJobanek reviewed Dec 4, 2017

View reviewed changes

dipak-pawar added 9 commits December 5, 2017 08:30

* documentation changes

9994449

* code refactoring

Moved all skipChecker to checker package

5debb68

Merge branch 'master' of https://github.com/arquillian/smart-testing …

4757070

…into issue_114

Merge branch 'master' of https://github.com/arquillian/smart-testing …

838d95f

…into issue_114

Merging into one test

b2c0e99

Update documentation

74042dc

Use SkipSTInstallationChecker in SmartTestingMavenConfigure

271aedb

update doc

e8df310

make mapToObject static

352d648

MatousJobanek requested changes Dec 11, 2017

View reviewed changes

moved SkipSTInstannationChecker logic to SkipInstallationChecker

ca75381

MatousJobanek approved these changes Dec 12, 2017

View reviewed changes

bartoszmajsak approved these changes Dec 12, 2017

View reviewed changes

bartoszmajsak assigned dipak-pawar Dec 12, 2017

bartoszmajsak changed the title ~~feat(#114): Implement configuration file per module.~~ feat(#114): implements configuration file per module. Dec 12, 2017

Merge branch 'master' of https://github.com/arquillian/smart-testing …

27e0713

…into issue_114

dipak-pawar merged commit a2f72dc into arquillian:master Dec 13, 2017


		import static org.arquillian.smart.testing.configuration.Configuration.SMART_TESTING_DISABLE;

		public class SkipSTInstallationChecker {

feat(#114): implements configuration file per module. #262

feat(#114): implements configuration file per module. #262

Conversation

dipak-pawar commented Nov 15, 2017

Changes proposed in this pull request:

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bartoszmajsak Nov 22, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dipak-pawar Nov 22, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bartoszmajsak left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

MatousJobanek Nov 28, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dipak-pawar Dec 4, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

MatousJobanek Dec 4, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dipak-pawar Dec 5, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dipak-pawar commented Dec 7, 2017

MatousJobanek left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bartoszmajsak Nov 22, 2017 •

edited

Loading

dipak-pawar Nov 22, 2017 •

edited

Loading

MatousJobanek Nov 28, 2017 •

edited

Loading

dipak-pawar Dec 4, 2017 •

edited

Loading

MatousJobanek Dec 4, 2017 •

edited

Loading

dipak-pawar Dec 5, 2017 •

edited

Loading

bartoszmajsak commented Dec 12, 2017 •

edited

Loading