Introduce Test-Driven Development (framework)

[Matthias Schoettle]

It is crucial to have (unit) tests for some of our components, especially the weaver, controller, validator; maybe the generator and GUI if possible.

This could be a project where a testing framework is set up.

[Matthias Schoettle]

I think each project should have it's own test source folder due to differences in each of them.

[Matthias Schoettle]

I found TestNG, which could be an interesting alternative to JUnit.

http://testng.org/doc/index.html

[Matthias Schoettle]

As part of #403 I created tests for the controllers using test data. These could serve as the basis for a general test class for controller tests. Right now, Checkstyle is disabled, maybe a more relaxed rule sets could be interesting.

[Matthias Schoettle]

Pull request #76 is leading to determining how to properly do the tests.

Current comments from reviewers:

1. Properly name the test cases to know what they are testing for (this means not asserting too many things per test case)
2. Instead of testing that a certain number of elements was removed, assert that exactly certain elements are there
3. Instead of the abstract controller test class, it should be in each test class (it's ok to duplicate)
4. We might want to have our own annotation to load a certain model per test case

Item 2 requires another library, because JUnit's assertEquals nor Harmcrest's assertThat(actual, is(expected)) or assertThat(actual, IsIterableContainingInOrder.contains(expectedFragments.toArray())) (which requires the harmcrest library to be included) does not report on the diff of both lists. The latter actually stops as soon as the first difference is reported. So, the error messages are not very helpful.

I found assertj (http://joel-costigliola.github.io/assertj/index.html), which evolved from FEST-assert. It provides a lot of cool features and assertThat(actual).containsOnlyElementsOf(expected) reports exactly what was missing and was too much. The only disadvantage is that this one does not care about the order. However, the error message of containsExactlyElementsOf is too vague. But they can be combined, e.g., containsOnlyElementsOf(expected).containsExactlyElementsOf(expected) if I understand correctly. Then if the first passes, the exact order is checked if necessary.

Also, it is possible to collect all failed assertions and report them all: http://joel-costigliola.github.io/assertj/assertj-core-features-highlight.html#soft-assertions

Item4: I found this post, but have to try it out: http://blog.jiffle.net/post/41125006846/extending-junit-functionality-with-additional

[Matthias Schoettle]

References #185: Exludes models directory from source folder.

→ <<cset 0f2f8577c562>>

[Matthias Schoettle]

References #185: Refactors test cases for better understanding.

• removes abstract test class and moves its operations to each test class
• introduces rule ModelWatcher which allows to specify a default model file name and observes annotated test cases for the @Model annotation
• introduces @Model annotation to be able to specify a specific model that needs to be loaded for that test case

→ <<cset 2d6f6d58ed5b>>

[Matthias Schoettle]

References #185: Adds AssertJ library.

• adds example of usage of AssertJ to testRemoveMessages_NestedNestedBehaviour_ContentsAndEmptyLifelineRemoved
• makes use of soft assertions to collect all failed ones
• adds helper methods to determine expected results easier

→ <<cset 3ba5ac099137>>

[Matthias Schoettle]

References #185: Adds additional helper methods.

• adds getClassifierByName and getOperationByName, which both make sure that the required element exists and is unique
• changes loadData to loadMessage, which now takes the class and operation name

→ <<cset ddc5809a56a8>>

[Matthias Schoettle]

References #185: Moves utility classes into util package and adds ModelResource rule.

ModelResource takes the job of loading and unloading a model. Each test can instantiate it and provide the implementation of the abstract methods.

→ <<cset 448e3536a0ed>>

[Matthias Schoettle]

References #185: Refactors test cases of MessageViewControllerTest.

• adds RemovalTestHelper rule to be used in all test cases to check for required changes uniformly
• changes test cases to check specifically for removed elements by checking if only expected values are there
• adds utility classes for message views and tests

→ <<cset 68b195c51d19>>

[Matthias Schoettle]

References #185: Moves loading of message view and getting affected messages to test util class.

→ <<cset e000c42ba3ef>>

[Matthias Schoettle]

References #185: Refactors test cases of FragmentsControllerTest.

• changes tests to use AssertJ
• makes use of new utility methods

→ <<cset 5bd253005b3b>>

[Matthias Schoettle]

References #185: Updates AssertJ to v3.5.1 and adds javadoc.

→ <<cset 0d05331e3558>>

[Matthias Schoettle]

References #185: Enables Checkstyle for util package and adds comments.

In addition, moves AssertJ to separate lib folder.

→ <<cset ecf21f0d9af6>>

[Matthias Schoettle]

Merged in Issues/403-temporary-properties into master. See pull request #76 for more details.

[Matthias Schoettle]

Possible option would be to extract tests into its own project, which would allow to import AssertJ once and also provide utility classes and methods across all projects.

In that case I would suggest to use Java 8 for that project in order to have better exception support. See: http://joel-costigliola.github.io/assertj/assertj-core-features-highlight.html#exception-assertion.

[Matthias Schoettle]

References #185: Improves ModelResource by adding capabilities of ModelWatcher to it.

ModelResource now has the default model file name and checks for the @Model annotation.

→ <<cset b95b2e1e1131>>