Generate assertions for Java records

[Berlizov]

Records are supported, but through a hack:

import org.assertj.assertions.generator.GenerateAssertion;

@GenerateAssertion
public record Item(String name, Integer value) {}

If you add the @GenerateAssertion, it generates a full Assert class:

@javax.annotation.Generated(value="assertj-assertions-generator")
public abstract class AbstractItemAssert<S extends AbstractItemAssert<S, A>, A extends Item> extends AbstractObjectAssert<S, A> {
  protected AbstractItemAssert(A actual, Class<S> selfType) {...}
  public S hasHashCode(int hashCode) {...}
  public S hasName(String name) {...}
  public S hasToString(String toString) {...}
  public S hasValue(Integer value) {...}
}

But there are three disadvantages:

• need to add the annotation to each record, or to a class that not uses old-school getter notation (getFoo);
• not everyone wants to add a new dependency (org.assertj:assertj-assertions-generator) to a project just for one annotation;
• this approach generates garbage hasHashCode and hasToString methods. But of course, all standard AbstractAssert's methods such as asString remain.

[scordio]

We are currently focusing on the next release for AssertJ. As soon as that is done, we'll revamp the generator projects and address these additional topics.

[timo-a]

Hi @Berlizov,

I cannot make your hack work in my example project (using the gradle plugin for the generator), am I missing something? The job summary shows the generated file: https://github.com/timo-a/microservice-example/actions/runs/10048164798 I'm just running generateAssertJ to sidestep the javax annotations that would cause a build to fail. Locally, I'm running $ ./gradlew :generateAssertJ, PRs against the branch demo/assertj/records-workaround-with-annotation will trigger a new run.

Update: I tried it with the maven plugin as well, to no avail (I hope I'm overlooking something). As before in gradle: The job summary shows the generated file: https://github.com/timo-a/debug-assertj-maven-plugin/actions/runs/10125183976, repository to reproduce, PRs against demo/assertj/records-workaround-with-annotation will trigger a rerun.
Locally the commands are mvn compile; mvn assertj:generate-assertions.

[timo-a]

We are currently focusing on the next release for AssertJ. As soon as that is done, we'll revamp the generator projects and address these additional topics.

I don't mean to create any pressure @scordio, I appreciate what is there already, I'm busy myself and cannot promise to contribute anything either. However, seeing as there has been a new release since your comment, and there is a PR for this issue already, is there anything outside contributors can do to speed up the resolution of this particular issue? Maybe tackle a number of higher priority issues?

While not as important as the core, I think that in the scope of custom assertion generation this is a key issue for projects with Java 17+ as a lot of the types to generate custom assertions for can be records.

[scordio]

@timo-a yes, definitely. Such issues are not forgotten 🙂

We couldn't spare time for the generator in the last months but I plan to jump on it in August.

[scordio]

Team decision: We will start the development of the next major version with Java 17 as a baseline to better aid records and jakarta support.

[timo-a]

Gentle check-in, is there something outside contributors can help to get this issue resolved? Does the java 17 baseline for instance imply any steps to be taken, like updating the workflow?

[scordio]

Thanks for the offer, @timo-a! We're already working on it.