Expanders Assert 1.0.0
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
void test_createsDataElement(TestExpansion<ApplicationComposite> testExpansion) {
testExpansion.afterRunningTransmutation()
.assertThatTransmuter()
.hasCreatedElement(dataElement("elements::City"));
}
@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
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
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.
<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)
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.