This PR adds a new version of Assertion.Builder<T>.propertiesAreEqualTo that takes a list of ignored properties in the form of KProperty. When comparing property by property, the ignored properties will be skipped.
Rationale
The new functionality needs to go into a new function, as the existing one is an infix function and therefore can't have a second parameter
The new parameter is of type KProperty as it's convenient and fits in with the rest of the strikt API. The downside is that getters/setters from Java can not be passed in as they are functions, which is an acceptable limitation in my opinion as the function is explicitly called propertiesAreEqualTo. In addition to that, the existing logic compares field names and not getters/setters, so that would be confusing anyway
I did not pursue the idea mentioned in the issue of a more fancy syntax like expectThat(subject).ignoring(...).propertiesAreEqualTo(...) as I don't think the current assertion builder design allows for it and I don't think it would be appreciated if an external contribution changes fundamentals like that
Usage example
data class SomeClass(id: String, name: String)
val subject = SomeClass("123", "Christian")
val other = SomeClass("123", "Rob")
// fails with existing propetiesAreEqualTo
expectThat(subject) propertiesAreEqualTo other
// passes with new propertiesAreEqualToIgnoring
expectThat(subject).propertiesAreEqualToIgnoring(other, SomeClass::name)
Happy to discuss and adjust the name of the function or the implementation.
Closes https://github.com/robfletcher/strikt/issues/167.
This PR adds a new version of
Assertion.Builder<T>.propertiesAreEqualTo
that takes a list of ignored properties in the form ofKProperty
. When comparing property by property, the ignored properties will be skipped.Rationale
infix
function and therefore can't have a second parameterKProperty
as it's convenient and fits in with the rest of the strikt API. The downside is that getters/setters from Java can not be passed in as they are functions, which is an acceptable limitation in my opinion as the function is explicitly called propertiesAreEqualTo. In addition to that, the existing logic compares field names and not getters/setters, so that would be confusing anywayexpectThat(subject).ignoring(...).propertiesAreEqualTo(...)
as I don't think the current assertion builder design allows for it and I don't think it would be appreciated if an external contribution changes fundamentals like thatUsage example
Happy to discuss and adjust the name of the function or the implementation.