assertj / assertj-assertions-generator-maven-plugin Goto Github PK
View Code? Open in Web Editor NEWA maven plugin to generate assertions for your custom types
License: Other
A maven plugin to generate assertions for your custom types
License: Other
We are using assertj-assertions-generator-maven-plugin 1.4.1 in a JavaFX projet to generate assertions for a variety of classes. Recently my team discovered that the plugin fails to create assertions for certain getter methods in combination with generics and interfaces.
The problem can be reproduced with the following code:
Interface - Please note that the return type is List:
package demo;
import java.util.List;
public interface MyInterface {
public abstract List<String> getMyList();
}
Implementing Bean, (generated with Xtend) - Please note that the return type of getMyList() is specialized to ObservableList, which is compatible to List:
package demo;
import demo.MyInterface;
import javafx.beans.property.ObjectProperty;
import javafx.beans.property.SimpleObjectProperty;
import javafx.collections.FXCollections;
import javafx.collections.ObservableList;
import xtendfx.beans.FXBindable;
@FXBindable
@SuppressWarnings("all")
public class MyClass implements MyInterface {
private ObservableList<String> myList = FXCollections.<String>observableArrayList();
public MyClass(final ObservableList<String> myList) {
ObservableList<String> _myList = this.getMyList();
_myList.addAll(myList);
}
private SimpleObjectProperty<ObservableList<String>> myListProperty;
public ObservableList<String> getMyList() {
return (this.myListProperty != null)? this.myListProperty.get() : this.myList;
}
public void setMyList(final ObservableList<String> myList) {
if (myListProperty != null) {
this.myListProperty.set(myList);
} else {
this.myList = myList;
}
}
public ObjectProperty<ObservableList<String>> myListProperty() {
if (this.myListProperty == null) {
this.myListProperty = new SimpleObjectProperty<ObservableList<String>>(this, "myList", this.myList);
}
return this.myListProperty;
}
}
Error message on Maven Build:
====================================
AssertJ assertions generation report
====================================
--- Generator input parameters ---
Generating AssertJ assertions for classes:
- demo.MyClass
--- Generator results ---
Assertions failed with error : java.lang.Class cannot be cast to java.lang.reflect.ParameterizedType
- Given classes were : [demo.MyClass]
Full error stack : java.lang.ClassCastException: java.lang.Class cannot be cast to java.lang.reflect.ParameterizedType
at org.assertj.assertions.generator.description.converter.ClassToClassDescriptionConverter.getParameterizedTypeOf(ClassToClassDescriptionConverter.java:147)
at org.assertj.assertions.generator.description.converter.ClassToClassDescriptionConverter.getTypeDescription(ClassToClassDescriptionConverter.java:120)
at org.assertj.assertions.generator.description.converter.ClassToClassDescriptionConverter.doGetterDescriptionsOf(ClassToClassDescriptionConverter.java:75)
at org.assertj.assertions.generator.description.converter.ClassToClassDescriptionConverter.getterDescriptionsOf(ClassToClassDescriptionConverter.java:62)
at org.assertj.assertions.generator.description.converter.ClassToClassDescriptionConverter.convertToClassDescription(ClassToClassDescriptionConverter.java:51)
at org.assertj.maven.generator.AssertionsGenerator.generateAssertionsFor(AssertionsGenerator.java:103)
at org.assertj.maven.AssertJAssertionsGeneratorMojo.executeWithAssertionGenerator(AssertJAssertionsGeneratorMojo.java:127)
at org.assertj.maven.AssertJAssertionsGeneratorMojo.execute(AssertJAssertionsGeneratorMojo.java:119)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
In some specific case the assertions generated by the plugin do not compile. This seems to happen randomly - I've prepared a simple example module (assertj-generator-bug.zip) that on my machine fails about 50% of the time.
$ unzip assertj-generator-bug.zip
$ cd assertj-generator-bug
$ mvn clean install
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------< com.exampl:assertj-generator-bug >------------------
[INFO] Building assertj-generator-bug 1.0-SNAPSHOT
[INFO] --------------------------------[ jar ]---------------------------------
[INFO]
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ assertj-generator-bug ---
[INFO] Deleting /home/USERS/mpiela/devel/tmp/assertj-generator-bug/target
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ assertj-generator-bug ---
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] Copying 0 resource
[INFO]
[INFO] --- maven-compiler-plugin:3.3:compile (default-compile) @ assertj-generator-bug ---
[INFO] Changes detected - recompiling the module!
[WARNING] File encoding has not been set, using platform encoding UTF-8, i.e. build is platform dependent!
[INFO] Compiling 2 source files to /home/USERS/mpiela/devel/tmp/assertj-generator-bug/target/classes
[INFO]
[INFO] --- assertj-assertions-generator-maven-plugin:2.2.0:generate-assertions (default) @ assertj-generator-bug ---
[INFO] JUnit not found in project classpath => JUnitSoftAssertions entry point class won't be generated.
[INFO]
====================================
AssertJ assertions generation report
====================================
--- Generator input parameters ---
Generating AssertJ assertions for classes:
- com.example.SomeService
--- Generator results ---
Directory where custom assertions files have been generated:
- /home/USERS/mpiela/devel/tmp/assertj-generator-bug/target/generated-test-sources/assertj-assertions
Custom assertions files generated:
- /home/USERS/mpiela/devel/tmp/assertj-generator-bug/target/generated-test-sources/assertj-assertions/com/example/SomeServiceAssert.java
Assertions entry point class has been generated in file:
- /home/USERS/mpiela/devel/tmp/assertj-generator-bug/target/generated-test-sources/assertj-assertions/com/example/Assertions.java
SoftAssertions entry point class has been generated in file:
- /home/USERS/mpiela/devel/tmp/assertj-generator-bug/target/generated-test-sources/assertj-assertions/com/example/SoftAssertions.java
[INFO]
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ assertj-generator-bug ---
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory /home/USERS/mpiela/devel/tmp/assertj-generator-bug/src/test/resources
[INFO]
[INFO] --- maven-compiler-plugin:3.3:testCompile (default-testCompile) @ assertj-generator-bug ---
[INFO] Changes detected - recompiling the module!
[WARNING] File encoding has not been set, using platform encoding UTF-8, i.e. build is platform dependent!
[INFO] Compiling 3 source files to /home/USERS/mpiela/devel/tmp/assertj-generator-bug/target/test-classes
[INFO] -------------------------------------------------------------
[ERROR] COMPILATION ERROR :
[INFO] -------------------------------------------------------------
[ERROR] /home/USERS/mpiela/devel/tmp/assertj-generator-bug/target/generated-test-sources/assertj-assertions/com/example/SomeServiceAssert.java:[37,38] cannot find symbol
symbol: class E
location: class com.example.SomeServiceAssert
[ERROR] /home/USERS/mpiela/devel/tmp/assertj-generator-bug/target/generated-test-sources/assertj-assertions/com/example/SomeServiceAssert.java:[57,69] cannot find symbol
symbol: class E
location: class com.example.SomeServiceAssert
[ERROR] /home/USERS/mpiela/devel/tmp/assertj-generator-bug/target/generated-test-sources/assertj-assertions/com/example/SomeServiceAssert.java:[80,42] cannot find symbol
symbol: class E
location: class com.example.SomeServiceAssert
[ERROR] /home/USERS/mpiela/devel/tmp/assertj-generator-bug/target/generated-test-sources/assertj-assertions/com/example/SomeServiceAssert.java:[100,73] cannot find symbol
symbol: class E
location: class com.example.SomeServiceAssert
[ERROR] /home/USERS/mpiela/devel/tmp/assertj-generator-bug/target/generated-test-sources/assertj-assertions/com/example/SomeServiceAssert.java:[124,46] cannot find symbol
symbol: class E
location: class com.example.SomeServiceAssert
[ERROR] /home/USERS/mpiela/devel/tmp/assertj-generator-bug/target/generated-test-sources/assertj-assertions/com/example/SomeServiceAssert.java:[145,77] cannot find symbol
symbol: class E
location: class com.example.SomeServiceAssert
[INFO] 6 errors
[INFO] -------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1.157 s
[INFO] Finished at: 2019-06-17T11:55:59+02:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.3:testCompile (default-testCompile) on project assertj-generator-bug: Compilation failure: Compilation failure:
[ERROR] /home/USERS/mpiela/devel/tmp/assertj-generator-bug/target/generated-test-sources/assertj-assertions/com/example/SomeServiceAssert.java:[37,38] cannot find symbol
[ERROR] symbol: class E
[ERROR] location: class com.example.SomeServiceAssert
[ERROR] /home/USERS/mpiela/devel/tmp/assertj-generator-bug/target/generated-test-sources/assertj-assertions/com/example/SomeServiceAssert.java:[57,69] cannot find symbol
[ERROR] symbol: class E
[ERROR] location: class com.example.SomeServiceAssert
[ERROR] /home/USERS/mpiela/devel/tmp/assertj-generator-bug/target/generated-test-sources/assertj-assertions/com/example/SomeServiceAssert.java:[80,42] cannot find symbol
[ERROR] symbol: class E
[ERROR] location: class com.example.SomeServiceAssert
[ERROR] /home/USERS/mpiela/devel/tmp/assertj-generator-bug/target/generated-test-sources/assertj-assertions/com/example/SomeServiceAssert.java:[100,73] cannot find symbol
[ERROR] symbol: class E
[ERROR] location: class com.example.SomeServiceAssert
[ERROR] /home/USERS/mpiela/devel/tmp/assertj-generator-bug/target/generated-test-sources/assertj-assertions/com/example/SomeServiceAssert.java:[124,46] cannot find symbol
[ERROR] symbol: class E
[ERROR] location: class com.example.SomeServiceAssert
[ERROR] /home/USERS/mpiela/devel/tmp/assertj-generator-bug/target/generated-test-sources/assertj-assertions/com/example/SomeServiceAssert.java:[145,77] cannot find symbol
[ERROR] symbol: class E
[ERROR] location: class com.example.SomeServiceAssert
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
if I set the generateAssertionsInPackage option, the generated assertion classes don't use the value set.
ex.
<generateAssertionsInPackage>com.example.assertions</generateAssertionsInPackage>
in the Assertion entry point class, that value is not used
If a project depend on library A, plugin should be able to generate custom assertions for classes in A.
Square Wire emits classes that have lower snake case public final fields. When I run the generator, currently nothing meaningful is generated, probably due to this.
There is an error in the documentation on this page:
http://joel-costigliola.github.io/assertj/assertj-assertions-generator-maven-plugin.html
Under the heading "Including and excluding classes from assertion generation" there is an example which shows an <excludes>
element which is nested inside the <packages>
element.
<configuration>
<packages>
<param>com.google.common.net</param>
<excludes>
<param>.*google.*HostSpecifier</param>
<param>.*google.*Headers</param>
<param>.*google.*Escaper.*</param>
</excludes>
</packages>
</configuration>
This is incorrect. The <excludes>
element must not be inside the <packages>
element.
The example should look like this:
<configuration>
<packages>
<param>com.google.common.net</param>
</packages>
<excludes>
<param>.*google.*HostSpecifier</param>
<param>.*google.*Headers</param>
<param>.*google.*Escaper.*</param>
</excludes>
</configuration>
Running Javadoc on the generated classes fails:
error: unexpected end tag:
</code>
[ERROR]/** Creates a new </code>{@link JUnitSoftAssertions}</code>. */
error: unexpected end tag:</code>
[ERROR]/** Creates a new </code>{@link SoftAssertions}</code>. */
warning: nested tag not allowed:
<b>
Verifies that the actual Addresses's addresses contains<b>
only<b>
the given Address elements and nothing else in whatever order.
The first two exist in every project where these classes are generated (it's the constructor comments). The third one is generated in Assert classes where the actual classes have collection type members.
Please add skip option for easier activate/deactivate the plugin.
Hi,
if I want to add some assertions of my own (e.g. hasX), how should I do that so that they are not wiped out every time I regenerate the file?
When running a multi-threaded build, we get the following warning.
[WARNING] *****************************************************************
[WARNING] * Your build is requesting parallel execution, but project *
[WARNING] * contains the following plugin(s) that have goals not marked *
[WARNING] * as @threadSafe to support parallel building. *
[WARNING] * While this /may/ work fine, please look for plugin updates *
[WARNING] * and/or request plugins be made thread-safe. *
[WARNING] * If reporting an issue, report it against the plugin in *
[WARNING] * question, not against maven-core *
[WARNING] *****************************************************************
[WARNING] The following plugins are not marked @threadSafe in activation-code-commons:
[WARNING] org.assertj:assertj-assertions-generator-maven-plugin:2.2.0
[WARNING] Enable debug to see more precisely which goals are not marked @threadSafe.
[WARNING] *****************************************************************
Can we mark the plugin as thread safe?
Since 2.2.0, when includePackagePrivateClasses option is enabled, package private assertions classes are referenced in the entry points assertions classes, like BddAssertions...
Which can cause compilation errors when these entry points classes are not generated in the same package.
As workarounds, the following plugin configurations can be applied :
Ideally, package private classes should not be referenced in entry points classes
Would be nice to add an option to make the generated SoftAssertions implement AutoCloseable, like so:
public class SoftAssertions extends org.assertj.core.api.SoftAssertions implements AutoCloseable {
@Override
public void close() {
assertAll();
}
}
I am facing this issue when migrating my application from JDK8 to JDK11.
[ERROR] Failed to execute goal org.assertj:assertj-assertions-generator-maven-plugin:2.1.0:generate-assertions (default) on project mws-inbound: Execution default of goal org.assertj:assertj-assertions-generator-maven-plugin:2.1.0:generate-assertions failed: A required class was missing while executing org.assertj:assertj-assertions-generator-maven-plugin:2.1.0:generate-assertions: org.junit.rules.TestRule
[ERROR] -----------------------------------------------------
[ERROR] realm = plugin>org.assertj:assertj-assertions-generator-maven-plugin:2.1.0
[ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
[ERROR] urls[0] = file:/C:/Users/admin/.m2/repository/org/assertj/assertj-assertions-generator-maven-plugin/2.1.0/assertj-assertions-generator-maven-plugin-2.1.0.jar
[ERROR] urls[1] = file:/C:/Users/admin/.m2/repository/org/assertj/assertj-assertions-generator/2.1.0/assertj-assertions-generator-2.1.0.jar
[ERROR] urls[2] = file:/C:/Users/admin/.m2/repository/org/apache/commons/commons-lang3/3.5/commons-lang3-3.5.jar
[ERROR] urls[3] = file:/C:/Users/admin/.m2/repository/commons-cli/commons-cli/1.2/commons-cli-1.2.jar
[ERROR] urls[4] = file:/C:/Users/admin/.m2/repository/com/google/guava/guava/20.0/guava-20.0.jar
[ERROR] urls[5] = file:/C:/Users/admin/.m2/repository/ch/qos/logback/logback-classic/1.0.13/logback-classic-1.0.13.jar
[ERROR] urls[6] = file:/C:/Users/admin/.m2/repository/ch/qos/logback/logback-core/1.0.13/logback-core-1.0.13.jar
[ERROR] urls[7] = file:/C:/Users/admin/.m2/repository/org/assertj/assertj-core/2.9.1/assertj-core-2.9.1.jar
[ERROR] urls[8] = file:/C:/Users/admin/.m2/repository/commons-collections/commons-collections/3.2.1/commons-collections-3.2.1.jar
[ERROR] urls[9] = file:/C:/Users/admin/.m2/repository/commons-io/commons-io/2.5/commons-io-2.5.jar
[ERROR] urls[10] = file:/C:/Users/admin/.m2/repository/backport-util-concurrent/backport-util-concurrent/3.1/backport-util-concurrent-3.1.jar
[ERROR] urls[11] = file:/C:/Users/admin/.m2/repository/org/codehaus/plexus/plexus-interpolation/1.11/plexus-interpolation-1.11.jar
[ERROR] urls[12] = file:/C:/Users/admin/.m2/repository/org/codehaus/plexus/plexus-utils/1.5.15/plexus-utils-1.5.15.jar
[ERROR] Number of foreign imports: 1
[ERROR] import: Entry[import from realm ClassRealm[maven.api, parent: null]]
[ERROR]
Any idea?
Currently, the generator plugin always generates the assertion class which requires the test-compile
step of Maven to compile the classes in every run - even if no source code has changed. The assertion classes should only be generated:
Example:
I want to create assertions for class A
:
A
do not exist -> generate assertion classA
exists and class A
was not changed since the generation -> do not generate assertion classA
exists and class A
was changed since the generation -> generate a new version of the assertion classPlugin is generating assertions for test classes and code generated by other plugins.
It will be nice if plugin will be able to distinguish between different code sources for same package and generate assertions only for chosen ones.
Currently it is only possible to exclude them using exludes like this:
<excludes>
<param>.*?\..*Test</param>
<param>.*?\.querydsl\.Q.*</param>
</excludes>
In my maven project, i have one module to put the models/DTOs codes and an other module to put the services/DAOs.
My Unit Test is in the module with services/DAOs and i want to generate the assertions of the model/DTO in the other module.
However, i find that this plugin cannot generate the assertions if the class is in an other module.
P.S. If the class is in same module, the assertion can be generated. But it is not the workaround for me.
The idea is to provide include and exclude patterns, include applied first and then exclude classes.
Due to the layout of the classes in my project, the generator will find existing Assert classes. The Generator will then try and create Assert classes, for the existing Assert classes. For example, I have MyObject, and a MyObjectAssert is correctly created. When I run "generate-assertions" again, I now get MyObjectAssertAssert. I suspect this would continue.
Can the Generate be changed to ignore files that implement Assert, or whose filename ends in Assert?
Is it possible to use Assertions class generated by this maven plugin inside generated assertions in the same package?
f.e. If we have Cart class and Item class.
public class Cart {
private List items;
}
public class Item {
private String name;
private Integer quantity;
...
}
So method in CartAssert.assertThat(List items) uses ItemAssert for comparing items. Right now standard Assertions class is used.
If the classes you want to generate assertions for are defined in src/test/java, plugin won't find them.
Can you please cut a new release that depends on the newly released 2.2.1 version of the assertj-assertions-generator
I am trying to build a library with OpenJDK 11 with the maven-assertj-generator plugin enabled. However, the plugin succeeds, but generates non-compiling code.
Has anyone had any succes on running the assertj-generator with OpenJDK 11?
Generated code:
/**
* Verifies that the actual Melding's referenties contains the given interface Referentie elements.
* @param referenties the given elements that should be contained in actual Melding's referenties.
* @return this assertion object.
* @throws AssertionError if the actual Melding's referenties does not contain all given interface Referentie elements.
*/
public MeldingAssert hasReferenties(interface Referentie... referenties) {
// check that actual Melding we want to make assertions on is not null.
isNotNull();
// check that given interface Referentie varargs is not null.
if (referenties == null) failWithMessage("Expecting referenties parameter not to be null.");
// check with standard error message, to set another message call: info.overridingErrorMessage("my error message");
Iterables.instance().assertContains(info, actual.getReferenties(), referenties);
// return the current assertion for method chaining
return this;
}
Wrong line:
public MeldingAssert hasReferenties(interface Referentie... referenties) {
Expected line:
public MeldingAssert hasReferenties(Referentie... referenties) {
To solve the issue, I tried building the assertj-assertions-generator on OpenJDK 11, but I also ran into all kinds of trouble.
Kindly add the "@generated" annotation - javax.annotation.Generated. This helps IDE users recognize that these classes are generated code, and should not be edited.
Hi,
I'm generating the assertion by using the class from another signed jar file. When I execute the test case, it shows me the exception as the following:-
signer information does not match signer information of other classes in the same package
I'm not sure if it is possible to change the generated package name or not. Could you please help to advise further? Thank you very much for your help in advance. I'm looking forward to hearing from you soon.
Regards,
Charlee Ch.
TL;DR
I've to implement the service whose return type is defined at the APIs project as the following:-
//The APIs: package com/foo/api
public interface MyResponse {
int getStatus();
String getMessage();
}
public interface Service {
MyResponse doSomething();
}
<!-- The implementation pom.xml-->
<plugin>
<groupId>org.assertj</groupId>
<artifactId>assertj-assertions-generator-maven-plugin</artifactId>
<executions>
<execution>
<id>generate-assertj</id>
<goals>
<goal>generate-assertions</goal>
</goals>
<configuration>
<packages>
<!-- Generate from the signed jar file -->
<package>com.foo.api</package>
</packages>
</configuration>
</execution>
</executions>
</plugin>
<dependencies>
<!-- The dependency to the signed jar file-->
<dependency>
<groupId>com.foo</groupId>
<artifactId>foo-api</artifactId>
<scope>compile</scope>
</dependency>
</dependencies
//The Implementation package com/foo/impl
public class MyResponseImpl implements MyResponse {
@Override
public int getStatus() {
}
public void setStatus(final int status) {
}
@Override
public String getMessage() {
}
public void setMessage(final String message) {
}
}
public class ServiceImpl implements Service {
@Override
public MyResponse doSomething() {
//some business logic
MyResponseImpl res = new MyResponseImpl();
res.setStaus(0);
res.setMessage("Success");
return res;
}
}
// The test case for the implementation
@RunWith(Arquillian.class)
public class MyServiceImplTester {
@Test
public void whenEnsureService() {
MyResponse response = service.doSomething();
Assertions.assertThat(response).hasStatus(0);
Assertions.assertThat(response).hasMessage("Success");
}
}
I have a project that has the assertion generator configured. If I run mvn test-compile, then the assertions are correctly generated from my template and the test compile succeeds:
--- Generator input parameters ---
The following templates will replace the ones provided by AssertJ when generating AssertJ assertions :
- Using custom template for 'assertions entry point class' loaded from src/test/resources/templates/analysis_core_assertions_entry_point_class_template.txt
Generating AssertJ assertions for classes in following packages and subpackages:
- io.jenkins.plugins.analysis.core.model
However, if the same project is part of a multi-module build, then the templates are not found:
--- Generator input parameters ---
The following templates will replace the ones provided by AssertJ when generating AssertJ assertions :
- Use default 'assertions entry point class' assertion template as we failed to to read user template from src/test/resources/templates/analysis_core_assertions_entry_point_class_template.txt
Generating AssertJ assertions for classes in following packages and subpackages:
- io.jenkins.plugins.analysis.core.model
Today my project did not build because I renamed a class, and with the generation of assertions the old files we left untouched. Maybe the directory should be cleaned first?
When I update my maven build to use version 2.1.0 of the assertj-assertions-generator-maven-plugin
the build fails because some assertions were not generated. All affected classes are package protected classes, e.g.
final class MyClass {
// contents of the class omitted
}
The assertion reports lists the affected classes in this section:
No custom assertions files generated for the following input classes as they were not found:
Using version 2.0.0 the assertions for the package protected classes are generated.
Thus, I cannot update to version 2.1.0 because my tests will no longer compile. Increasing the visibility of the classes to public
just be make the generator plugin work is not an option.
Enhancement
Use case:
And I'd like to use a single "Assertions" class (entry point).
Configuration could be:
So basically the generator will copy all the model generated and custom
public static XxxxxAssert assertThat(Xxxxx actual) {
return new XxxxxAssert(actual);
}
into one class inheriting Assertions.
currently when you try to generate assertions for classes with same name the plugin will only create assertions for second.
Hello,
In the maven plugin assertj-assertions-generator-maven-plugin:2.2.0, I will like to select all classes in the "model" subpackages. Of course, I have multiple "model" subpackages in my project.
I didn't make it work, my actually pom.xml configuration is :
fr.mycompany.**.model
Did I make some mistakes in configuration ?
Or is this functionality with wildcards is unvailable ?
Thanks for your help !
Best Regards,
Fabien
Actual version is org.assertj:assertj-core:3.19.0
looks like v2 not supported and i have an error
Could not find artifact org.assertj:assertj-core:jar:[2.0.0,2.99.0] in central (https://repo1.maven.org/maven2)
When the generator plugin fails to create assertion classes (e.g. because of package protected class see #46) the build is not failed by the plugin. The build fails later when compiling the test sources. Since it is already clear at this point that the build will fail later, the plugin should fail the build immediately or at least provide an option to enable the fail-fast behaviour.
For example
class A {
enum Status {Active, Deleted}
}
class B {
enum Status {Yes, No}
}
This will create a file called StatusAssert.java, that seems to represent only one of the above enums. The Assertations.java will include just one of the assertThat(Status) methods, which may not be the actual one that was stored to disk.
When I have following classes configured
<classes>
<class>c.b.a.c.i.SomeClass</class>
<class>c.b.a.c.i.SomeOtherClass</class>
</classes>
plugin generates entry point class in c.b.a.c.i package, but when I add another class (order seems to does not matter)
<class>c.b.a.e.AnotherClass</class>
entry point class is being generated in c.b.a.e package, which breaks existing code.
Is there a way to configure where Assertions should be generated? Haven't found such option.
Possibly to target/generated-test-sources
?
I am new to AssertJ and can't get it to generate some assertions I expect it would.
Specifically, I have a class that implements the Java Comparable
interface and I try to use the 'isLessThan' type of assertions as shown in the ComparableAssertionsExamples example.
The class to be tested:
package some.package;
public final class ComparableClass implements Comparable<ComparableClass> {
private String attribute;
public ComparableClass(final String attr) { this.attribute = attr; }
public String getAttribute() { return this.attribute; }
public void setAttribute(final String attr) { this.attribute = attr; }
@Override
public int compareTo(final ComparableClass other) {
return this.attribute.compareTo(other.getAttribute());
}
@Override
public String toString() { return attribute; }
}
The test class:
package some.package;
import static some.package.Assertions.assertThat;
import static org.assertj.core.api.Assertions.assertThat;
import org.testng.annotations.Test;
public class ComparableClassTest {
@Test
public void basicTest() {
final ComparableClass a = new ComparableClass("a");
final ComparableClass b = new ComparableClass("b");
assertThat(a).hasAttribute("a");
assertThat(b).hasAttribute("b");
assertThat(a).isLessThan(b);
}
}
The error I get:
[...]ComparableClassTest.java:[15,22] cannot find symbol
symbol: method isLessThan(me.quis.assertj.ComparableClass)
location: class me.quis.assertj.ComparableClassAssert
I would have expected that I can use the isLessThan
type of assertions just fine.
I know how to work around this issue but I was wondering what the correct solution would be or if I did any mistakes in my set-up.
Workaround:
package some.package;
import static some.package.Assertions.assertThat;
import org.assertj.core.api.Assertions;
import org.testng.annotations.Test;
public class ComparableClassTest {
@Test
public void basicTest() {
final ComparableClass a = new ComparableClass("a");
final ComparableClass b = new ComparableClass("b");
assertThat(a).hasAttribute("a");
assertThat(b).hasAttribute("b");
Assertions.assertThat(a).isLessThan(b);
}
}
Please find attached an example project (assertj-comparable.tar.gz) that can be compiled with mvn assertj:generate-assertions test
to reproduce this problem.
With the help of the maven plugin I can create Assertions and SoftAssertions for my domain objects.
But for some domain objects I already have created handmae Asserts. Currently the assertThat(*) if have added there won't be included within the generated Assertions and SoftAssertions.
What do I wrong or maybe I haven't really understood the plugin?
Another thing I just wondered:
Why is the generated SoftAssertions not usable as JunitRule. Why not extending it from JUnitSoftAssertions?
The generated entry-point class is called Assertions. If I am using the std Assertions class and my generated Assertions class in the same test, I can only import one which means the usage of the other has to be fully qualified. It would be nice to be able to add a prefix so that the generated entry-point classes are name MyProjectAssertsion, MyProjectJUnitAssertions, etc.
Based on assertj/assertj-assertions-generator#33.
So that users can inject their own.
[WARNING] org.assertj.maven.AssertJAssertionsGeneratorMojo#project:
[WARNING] The syntax
[WARNING] @parameter expression="${property}"
[WARNING] is deprecated, please use
[WARNING] @parameter property="property"
[WARNING] instead.
Enhancement
Use case:
assertThat(objectA).hasFieldOfObjectA("field");
assertThat(objectA.objectB).hasFieldOfObjectB("fieldOfObjectB");
assertThat(objectA)
.hasFieldOfObjectA("field")
.withObjectB()
.hasFieldOfObjectB("fieldOfObjectB");
I already do that manually, but I think it could be useful to be able to add this behavior automatically.
What do you think?
If we find some of the input classes, we don't report the one we miss.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.