New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Kotlin interoperability #52
Comments
There’s indeed some inconsistency about how built-in arbitrary providers match types. I‘ll have a look at it. |
Fixed in 22af655 Available in 1.1.2-SNAPSHOT |
@tmohme Your approach with registering your own provider should also work. |
I'm wondering in what situations Kotlin produces the generic subtype, though. Might lead to quite a few type matching problems in various situations... |
Thx for the super fast reaction :)
Thx for the hint and your offer. As I already wrote, we were probably missing some knowledge (and persistence) here.
I'll play a bit with IntelliJ's Kolin byte-code viewer tomorrow . . . maybe I find out something useful. |
Just found out that you can use |
The change is more consistent anyway, And already deployed in 1.1.2. But good to know a workaround exists for future problems. |
Just got following on 1.1.6:
when signature is as following: @Property
fun test(@ForAll @Size(min = 1) names: List<@StringLength(min = 1, max = 20) String>) {
Assertions.assertEquals(names.toSet().joinToString(separator = ", "), CatalogUtils.toShortForm(names))
} |
@asm0dey Looking at the stack trace it should work, so |
I have maven only and I'll try to narrow it down to minimum reproducible example . |
For me, the following slightly modified snippet runs flawlessly with Kolin 1.3.41, jqwik 1.1.6, Gradle 5.5.1:
I guess a complete example-project is required to investigate this. |
Just a wild guess: Could it be that Kotlin's nullable type feature leads to a type mismatch with Java's standard types? |
It could! I had to say that my code under test is written in Java. Does it change anything? |
If I only knew. Actually I'll need a repo in order to debug the live running code and see what's going on. |
And I'm absolutely unable to create simple example :( |
Start with giving the full code including class declaration and all imports. Maybe we can work from there. |
It all starts here: https://github.com/php-coder/mystamps/blob/712c62384be3decb641e8993a8223f01b30d2f29/src/main/java/ru/mystamps/web/util/CatalogUtils.java#L72 |
@asm0dey I cannot find the tests in the repository which are probably the crucial part for tracking the problem. My current inkling is that your project setup is not correct. If, for example, module Maybe you can start from https://github.com/junit-team/junit5-samples/tree/r5.5.0/junit5-jupiter-starter-gradle-kotlin and then add jqwik as another testImplementation-dependency. |
Yeah, I didn't commit tests because they didn't work :) Anyways, I'll recheck everything again and will back to you if won't able to fix. Thank you! |
@asm0dey Any new insights? |
Nop. I think we should close this task until I have time to investigate |
Testing Problem
In Kotlin we want to express something like this:
which is (almost) the equivalent to the following Java code:
What looks easy and works out of the box with Java produces a
net.jqwik.api.CannotFindArbitraryException: Cannot find an Arbitrary for Parameter of type [@net.jqwik.api.ForAll(value=) List<? extends BigDecimal>]
with Kotlin.The difference is obviously the type signature which for Java is
List<BigDecimal>
while it isList<? extends BigDecimal>
for Kotlin.Due to this little difference, the
BigDecimalArbitraryProvider
decides that he is unable to provide values for the given targetType.Suggested Solution
The
BigDecimalArbitraryProvider
could use the more forgivingtargetType.isAssignableFrom(BigDecimal.class)
instead of the strictertargetType.isOfType(BigDecimal.class)
to determine if he is able to provide the requested values.The same applies to some of the other
*ArbitraryProviders
.Interestingly, currently not all
*ArbitraryProviders
are structured the same.While the providers for BigDecimal and BigInteger use
isOfType(...)
others (like Boolean, Integer, ...) useisAssignableFrom(...)
.Discussion
We tried to get around this by creating our own provider for BigDecimals, but experienced problems in the aftermath when we had trouble to let our provider correctly work with jqwik constraint annotations (like @BigRange). Probably we are missing some knowledge here . . .
The text was updated successfully, but these errors were encountered: