#33 Auto-reload for choices properties

a-polyudov commented 4 years ago

This is the draft for choices auto-reload feature (#33). Tests, documentation and some comments is still under implementation.

a-polyudov commented 4 years ago

I don`t realy know why Travis CI build was failed.

ChoicePropertiesTest#getCompositeChoices has @Disabled annotation, but this test was marked as FAILED (see build log)
I have trying to execute gradle build or gradle test on my computer and it works succeffuly all the times. However, there are 62 tests (61 passed and 1 ignored) according to my Intellij IDEA, but Travis CI ran 64 tests (62 passed and 2 failed)

Can I see a full report of Travis CI build?

Toparvion commented 4 years ago

I've added some Gradle options to make it print the test results right into the console (Travis), so we've got a chance to see them without digging into VM's file system. Then I've investigated the problem and here's what I've come to:

Both failed tests have the same reason - the absolute path hard coded by me into choices.yaml file (see its localPlainLogsBase section). This path was not analyzed previously, because the application tests didn't know about choices.yaml (since nobody provided them with the additional-location property). But now the file is specified in config/application.yaml which is the default location for Spring configuration scanner.
The absolute path itself is OK on Windows, but when the test is executed on any other platform, the underlying Path implementation does not consider it absolute. This leads to the assertion failing.
For the time being, I've replaced the absolute path with the corresponding placeholder (JVM's user.dir) but I think it's still not a good idea to rely on any paths that we don't control ourselves. A subject to discuss.
The JUnit behavior in relation to @Disabled annotation depends on the annotated element: if on a class, then the class is skipped entirely, but if on a method, then only the method (and its lifecycle support) is skipped but the containing class gets loaded and initialized. In our case, since the class has @SpringBootTest annotation, the initialization involves building the Spring context. This returns us to the previous point about invalid path in choices.yaml. As a proof-of-concept, I've relocated the annotation on the class level, but I think there should be a better solution since there is no strict reason to keep the test disabled. A subject to discuss as well.