Expanders Assert 1.0.0

info

Expanders-assert is a library for writing tests in expansion-resource projects. It has several improvements over the classic expanders-test-utils library and uses more modern libraries like JUnit 5 and AssertJ.

Expanders-assert now has its first major release. We were happy with the current API and are ready to mark it as stable. This means that subsequent changes will be kept backwards compatible.

Important Changes since 0.9.1

Since the 0.9.1 there have been a few changes that you can encounter when upgrading to 1.0.0.

• Transitive dependencies, like AssertJ, JUnit 5 and expanders-core have been set to provided. They will need to be added explicitly where needed.
• doesNotHaveTag() can now fail if the tag is not present on the Expander or Feature. This is to prevent false positives due to typo's.
• Test setup now fails if the TestExpansion parameter is typed incorrectly. This helps with prevent copy-paste errors.
• The class signature of the ValidationAssert class (returned by assertThatValidationRule()) has changed. This used to have a generic type related to the Composite type, but has been changed since it was not relevant.

New features

The latest changes focus on supporting missing support for transmuters.

Testing Transmuters

We've added more support to test transmuters. The assertThatTransmuter() method allows us to test the changes introduced by a transmuter.

Test the creation of a new element.

  @Test
  void test_createsDataElement(TestExpansion<ApplicationComposite> testExpansion) {
    testExpansion.afterRunningTransmutation()
        .assertThatTransmuter()
        .hasCreatedElement(dataElement("elements::City"));
  }

Test the creation of a new module element.

  @Test
  void test_createsComponent(TestExpansion<ApplicationComposite> testExpansion) {
    testExpansion.afterRunningTransmutation()
        .assertThatTransmuter()
        .hasCreatedModuleWith(
            moduleType("elements::JeeComponent"),
            moduleElement(
              identifiedAs(component("newComp")),
              with("some new DataElements", comp -> {
                comp.asInstanceOf(ComponentComposite.class)
                    .selectingAll(ComponentComposite::getDataElements)
                    .identities().containsExactlyInAnyOrder(
                        "newComp::Person",
                        "newComp::City");
              })));
  }

Test the creation of a new program element.

  @Test
  void test_createdAngularApp(TestExpansion<ApplicationComposite> testExpansion) {
    testExpansion
        .afterRunningTransmutation()
        .assertThatTransmuter()
        .hasCreatedProgramWith(
            programType("angularProjects::AngularApp"),
            programElement(identifiedAs(angularApp("cityApp"))));
  }

Conditions

net.democritus.expander.assertj.Assertions has a number of new methods returning AssertJ conditions for Composite objects.

  @Test
  void test_conditions(TestExpansion<DataElementComposite> testExpansion) {
    testExpansion.assertThatModel()
      .is(identifiedAs(dataElement("testComp::City"))) // Use onion-spec to verify type and identity
      .is(instanceOf(DataElementComposite.class)) // Verify type
      .is(identifier("testComp::City")) // Verify functional key
      .is(newElement()); // Verify that the element was not part of the input model
  }

Fixing classpath conflicts in tests

Version Conflicts in expansion-resource projects

By default, expanders-assert checks for conflicts in the classpath before running tests. If one of the expansion-resources in the classpath depends on a newer version of a resource than what is available in the classpath, it throws an exception.

This check has been added because these kind of conflicts often created unexpected and hard to trace errors. By failing early, we send the developer in the right direction of updating their dependencies. However, due to how resolution works in maven, this can easily break builds of automated update mechanisms.

To make the builds less brittle, there is a new configure-test-classpath goal in the expanders-maven-plugin. It updates the artifacts used to run tests to the latest version required by the expansion-resource dependencies. By updating these artifacts, the classpath will be closer to what it will be during expansion.

To use this fix in a project, add an execution to expanders-maven-plugin in the pom.xml.

pom.xml

<build>
  <plugins>
    <plugin>
      <groupId>net.democritus.maven.plugins</groupId>
      <artifactId>expanders-maven-plugin</artifactId>
      <version>${expanders-maven-plugin.version}</version>
      <executions>
        <execution>
          <id>fix-test-classpath</id>
          <goals>
            <goal>configure-test-classpath</goal>
          </goals>
        </execution>
      </executions>
    </plugin>
    <!-- ... -->
  </plugins>
</build>

For a multi-module maven project, you can add this to the root module. (Just don't accidentally configure it in pluginManagement)

Warnings

When updating artifacts, the plugin will still print warnings. The intent is to have developers manage their dependencies correctly, yet not obstruct them in updating single dependencies.