assertj: [WithAssertions] ListAssert is broken due to generics fluff
Summary
#775 fixed some discrepancies between WithAssertions
and Assertions
(shipped in 3.6.0). Unfortunately, I’m afraid that I got some generics wrong leading unwanted regression 😞
Example
public class RemoveMe implements WithAssertions {
@Test
public void fixme() {
List<String> l = new ArrayList<>();
assertThat(l).contains("foo");
}
}
Is broken since 3.6.0.
Error:(213, 18) java: no suitable method found for contains(java.lang.String)
method org.assertj.core.api.AbstractIterableAssert.contains(capture#3 of ? extends java.lang.String...) is not applicable
(varargs mismatch; java.lang.String cannot be converted to capture#3 of ? extends java.lang.String)
method org.assertj.core.api.ListAssert.contains(capture#3 of ? extends java.lang.String...) is not applicable
(varargs mismatch; java.lang.String cannot be converted to capture#3 of ? extends java.lang.String)
This is related to the addition of the following method:
default <T> ListAssert<? extends T> assertThat(final List<? extends T> actual)
I think that return type should be ListAssert<T>
, or ListAssert<? super T>
, rather than ListAssert<? extends T>
.
Do you want me to open a PR to fix it? Should we review the API to spot such mistakes?
Java 8 specific ?
- YES : create Pull Request from the
master
branch
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Comments: 24 (23 by maintainers)
Commits related to this issue
- Use method generic return type and generic parameters for testing the API consistency (#1005) Use Guava TypeResolver to be able to compare generic Types — committed to filiphr/assertj-core by filiphr 7 years ago
- Use method generic return type and generic parameters for testing the API consistency (#1005) Use Guava TypeResolver to be able to compare generic Types — committed to filiphr/assertj-core by filiphr 7 years ago
- Use method generic return type and generic parameters for testing the API consistency (#1005) Use Guava TypeResolver to be able to compare generic Types — committed to assertj/assertj by filiphr 7 years ago
- Align assertThat methods between Assertions and WithAssertions (#1005) — committed to filiphr/assertj-core by filiphr 7 years ago
- Add missing methods from Assertions to WithAssertions (#1005) — committed to filiphr/assertj-core by filiphr 7 years ago
- Add missing methods from Assertions to WithAssertions (#1005) — committed to filiphr/assertj-core by filiphr 7 years ago
- Align assertThat methods between Assertions and WithAssertions (#1005) — committed to assertj/assertj by filiphr 7 years ago
- Add missing methods from Assertions to WithAssertions (#1005) — committed to assertj/assertj by filiphr 7 years ago
I’ve created PR #1033 for the
2.x
branch. Once we get that one merged, I can make one for themaster
and hopefully we’ll have a consistent API across the entire framework 😄Fixed thanks to @filiphr ! @cykl moreover
WithAssertions
now have all utility method ofAssertions
(not onlyassertThat
methods)@joel-costigliola the
WithAssertions
should have the exact same methods as theAssertions
, right? not justassertThat
methods, but also the other ones as well.@filiphr Many thanks for taking over the task.
I haven’t seen any obvious oversight in the patch. I cannot test it over our projects because they all rely on 3.x.
Isn’t it possible to use the tests that are used to make sure that there are no differences between
Assertions
andBddAssertions
. I am not sure if we addedWithAssertions
when we added those tests.