Comments (3)
This is a bug, we don't register the fields of types that don't match the compared types when these types could have fields whose type are in the compared types list.
from assertj.
Thanks for reporting this, we'll look into it shortly !
from assertj.
As requested by @joel-costigliola
using version 3.24.2 the following assertion fails. Using 3.25.0-SNAPSHOT the assertion succeeds.
BuildRecipe buildRecipe = TestBuildRecipeBuilder.getBuildRecipe();
buildRecipe.getBuildItems().get(0).setBuildItemId("buildItemId");
buildRecipe.getBuildItems().get(0).getBuildItemChildren().get(0).setBuildItemChildId("buildItemChildId");
BuildRecipe buildRecipe2 = TestBuildRecipeBuilder.getBuildRecipe();
buildRecipe2.getBuildItems().get(0).setBuildItemId("buildItemId");
buildRecipe2.getBuildItems().get(0).getBuildItemChildren().get(0).setBuildItemChildId(null);
// basic recursive comparison
assertThat(buildRecipe2).usingRecursiveComparison().isNotEqualTo(buildRecipe);
// compare only the types with the differences. This doesn't work in 3.24.2 but does work in 3.25.0
assertThat(buildRecipe2).usingRecursiveComparison()
.comparingOnlyFieldsOfTypes(AbstractBuildItem.class, BuildItemChild.class)
.isNotEqualTo(buildRecipe);
// compare ignoring the types with the differences. This works in both versions
assertThat(buildRecipe2).usingRecursiveComparison()
.ignoringFieldsOfTypes(AbstractBuildItem.class, BuildItemChild.class)
.isEqualTo(buildRecipe);
Very nice!
I did notice one additional difference. The field name for 'setBuildItemId' is 'buildItemId' so I checked what would happen if I specified comparing only that fieldname:
BuildRecipe buildRecipe = TestBuildRecipeBuilder.getBuildRecipe();
buildRecipe.getBuildItems().get(0).setBuildItemId("buildItemId");
buildRecipe.getBuildItems().get(0).getBuildItemChildren().get(0).setBuildItemChildId("buildItemChildId");
BuildRecipe buildRecipe2 = TestBuildRecipeBuilder.getBuildRecipe();
buildRecipe2.getBuildItems().get(0).setBuildItemId("buildItemId");
buildRecipe2.getBuildItems().get(0).getBuildItemChildren().get(0).setBuildItemChildId(null);
// basic recursive comparison
assertThat(buildRecipe2).usingRecursiveComparison().isNotEqualTo(buildRecipe);
// compare only the fields with the differences.
// in 3.24.0 - Assertion error, objects are considered equal
// in 3.25.0 - IllegalArgumentException "The following fields don't exist: {buildItemChildId}{buildItemId}"
assertThat(buildRecipe2).usingRecursiveComparison()
.comparingOnlyFields("buildItemId", "buildItemChildId")
.isNotEqualTo(buildRecipe);
// compare ignoring the fields with the differences, this results in the same assertion error for both 3.24.2 and 3.25.0-SNAPSHOT
// in 3.24.2 - Assertion error:
// field/property 'buildItems[0].buildItemChildren[0].buildItemChildId' differ:
// - actual value : null
// - expected value: "buildItemChildId"
// in 3.25.0 - Assertion error, same as in 3.24.0
assertThat(buildRecipe2).usingRecursiveComparison()
.ignoringFields("buildItemId", "buildItemChildId")
.isEqualTo(buildRecipe);
from assertj.
Related Issues (20)
- assertThat(collection).doesNotHaveDuplicates() is not sorted, even if the collection is HOT 12
- Recursive comparison checks for existence of fields in types that parameterize nested unordered iterables HOT 1
- `satisfiesExactlyInAnyOrder` fails if `actual` overrides `equals` HOT 4
- `isNotEqualTo(boolean)` fails if `actual` is null HOT 2
- Suggesting "hasOnlyDuplicates()" assertion HOT 3
- Field existence check for the elements of a collection field HOT 1
- Checking compared fields existence: handle containers
- ...usingRecursiveComparison().ignoringTransientFields()... HOT 7
- Unable to compare some timestamp types HOT 3
- Add AbstractAssert#matchesWith HOT 1
- AssertFactory with the ability to convert the value upfront HOT 24
- Add default recursive comparison configuration for non accessible classes and fields HOT 6
- `extracting(Function...)` propagates `Object` instead of the common base type of all extractors HOT 6
- NPE with `extracting(Function... extractors)` HOT 3
- AssertJ: issue with Assertions.assertThat().usingRecursiveComparison().isEqualTo() HOT 6
- Provide reason and possible replacement for @Deprecated HOT 3
- AssertJ string assertions not working with Spock 2.3 and Groovy HOT 15
- isEqualTo on date can lead to unexpected failures when switching time zones HOT 6
- `InstanceOfAssertFactories.array` and `InstanceOfAssertFactories.array2D` expect array type parameter instead of the one for their elements HOT 1
- `AbstractOptionalDoubleAssert.hasValue(double)` fails with NaN HOT 11
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from assertj.