Known Limitations

Known Limitations

Current behaviour of the working tree (0.6.2-SNAPSHOT) that a user is likely to run into, with the issue that tracks each item. The issue tracker is the backlog; this page does not anticipate how an issue will be resolved.

Consumers run at different points — #9

Overload	Consumer runs	Set passed
isValid(Consumer), isValidFor(Class, String, Consumer)	before the emptiness check, so also when the assertion then fails	an unmodifiable view
isNotValid(Consumer), hasValidProperty(String, Consumer), the method and constructor hasValidParameters(…, Consumer) / hasValidReturnValue(…, Consumer)	only after the check passes	the provider's set

Consequently, a consumer can mutate the set in the second group (isNotValid(s -> s.clear()) succeeds), while in the first group the same lambda throws UnsupportedOperationException. Which contract is intended — observer or post-success hook, view or provider set — is undecided. Do not depend on either behaviour.

No consumer on the negative methods — #12

isNotValidFor, doesNotHaveValidProperty, doesNotHaveValidParameters and doesNotHaveValidReturnValue take no consumer. A test expecting a value to be invalid cannot see which constraint failed through them; either use isNotValid(Consumer) on the whole bean, the "before" consumers of isValid / isValidFor inside assertThatThrownBy, or call the Validator directly and use Inspecting Violations.

No path or template shortcuts on violation sets — #13

assertThatConstraintViolations(…) has the generic iterable vocabulary and typed element navigation, but nothing like "has a violation on name" or "has a violation with this template". Use filteredOn / extracting with a lambda. (assertThatConstraintViolationException(…).hasViolationOn(String) exists for the exception.)

No bean Condition for collections — #17

There is no Condition for assertThat(users).are(valid). A single bean is checked with assertThatBean(user).isValid(); a collection with allSatisfy(u -> assertThatBean(u).isValid()).

No module-info — #18

The jar carries only Automatic-Module-Name: com.github.jinahya.assertj.validation. On the module path it is an automatic module under that name.

AssertJ 4 is a milestone profile — #20

The main classes are compiled against AssertJ 3.27.7; 4.0.0-M1 is exercised only through the assertj-4 profile. The default moves once AssertJ 4.0.0 is final. See Build and Profiles.

Without an issue

• A lazy failure message is evaluated by property navigation. A message given as a supplier, with withFailMessage(Supplier), is evaluated on failure only by the validating methods and by nodes() / extracting…Node(index). Navigating further — into a node's name, index or key, or a descriptor's members — goes through AssertJ's own extracting(…), which copies the message eagerly and so evaluates the supplier even when the assertion passes.
• One provider. Only Hibernate Validator is on the test classpath. Behaviour that the specification leaves to the provider — node toString(), the property path of a parameter (arg0 vs. a real name), whether a validator from a closed factory is rejected — is observed on Hibernate Validator alone.
• @Valid is not followed by hasValidProperty / doesNotHaveValidProperty / isValidFor / isNotValidFor, because validateProperty and validateValue do not cascade by specification. See Validating Values.
• A per-call factory by default. Without usingValidator / usingValidatorFactory, every validating call builds and closes a ValidatorFactory. See Validator Lifecycle.
• A null created object passed to the constructor hasValidReturnValue is the provider's IllegalArgumentException, not an assertion failure.
• AbstractPathAssert.usingElementComparator / usingDefaultElementComparator throw UnsupportedOperationException; configure comparators on nodes().
• extractingConstraintsForProperty / extractingConstraintsForMethod return an assertion whose actual is null when nothing is constrained there, as the metadata API does; chain isNull() / isNotNull() or hasConstraintsForProperty accordingly.

Deliberately not provided

Recorded in the repository's _TODO.md so they are not re-litigated:

• a usingValidatorFactorySuppliedBy(Supplier<…>) that closes what it gets — see Validator Lifecycle;
• assertions for Validator.unwrap(Class), for bootstrap/configuration/SPI types, and for constraint annotations;
• per-concept assertion interfaces;
• a second validation implementation in the test build.