Test overriding default plugin configuration options

[AdamBJ]

There currently are no integration tests to verify the behavior of the plugin if default configuration values (i.e. outputPath, languageToGenerate, umpleFilePath) are overwritten. This is because we don't yet know how we're going to pass configuration to the plugin.

Once we decide how we're going to pass configuration information to the plugin this issue should be resolved.

[AdamBJ]

The TL;DR list of tests that need to be added

1. A test that uses the plugin to generate .java files and .class files from a Gradle project that doesn't overwrite the default plugin configuration values. Basically we need to do what we're doing for TestProject right now, but for a project that uses the default values rather than overriding them.
2. We currently only verify generated .java and .class files. When/if languages other than Java are added we'll need to extending the existing test framework to support them.

The current state of plugin tests

Unit tests and integrations tests have been added to the plugin. They can be run independently (gradle test for unit tests and gradle integrationTest for integration tests), or together. Both test suites are run when the gradle build task is executed.

There currently are no unit tests, but there are two kinds of integration tests: Basic (see Basic.groovy) and CompilationAndGeneration (see CompilationAndGeneration.groovy). The Basic tests apply the plugin to a project and then ensure that the project has a generateSource task that it can execute and also that the plugin has been registered with the project.

The CompilationAndGeneration integration tests are more comprehensive and centre on a multi-project build named TestProject. The tests invoke the compileJava task of the test project, which depends on the generateSource and compileGeneratedSourceJava tasks. Because of this dependency, after the compileJava task finishes executing we have a collection of .java and .class files that we can verify against expected outputs.

The verification step checks a number of properties of the generated files. First, it checks that the generated and compiled files aren't empty and have the names we expect. Then, if the file is a .java file, we use a SampleFileWriter from the main Umple project to verify that the contents of the generated file are correct.

After the verification steps are complete we delete all the generated folders so that nothing gets carried over to the next time we run the tests.

What tests need to be added

What we've got is a good start. However, we need to do a better job of testing the plugin using different configuration options. Essentially, there are two ways to configure the plugin. First, the user can rely on the default values that the plugin provides. These values are DEFAULT_LANGUAGE_TO_GENERATE, DEFAULT_GENERATED_OUTPUT_PATH, and DEFAULT_UMPLE_FILE_PATH and are stored in UmpleGradlePlugin.groovy. Second, the user can override the default values by creating ext properties on the generatedSource source set. See TestProject's build.gradle file for an example of how this works.

TestProject' build.gradle file overrides all three values. The verification step then checks that the generated files are in the user specified (i.e. non-default) locations. However, we currently have no test that verifies the plugin behaviour when the default configuration options aren't overridden. We need to add a test for this.

Unfortunately, Gradle is not particularly flexible when it comes to configuring projects from within JUnit. To my knowledge there is not way to modify the configuration of a project from within JUnit, so we can't just modify the properties of TestProject. That means that to test the plugin using the default path values rather than overridden class values, another test project will need to be added. Adding another project that is essentially the same as TestProject would introduce all sorts of duplicate code maintenance headaches though, so before going ahead with the "second external project" approach it may be worth doing more research to see if we can come up with something better.

[AdamBJ]

This testing style described in this issue doesn't really apply anymore. I'm closing it in favour of issue #21