Can we use Ctor or Fields with a parameterized class?
#62
Comments
|
I get this error if I use |
|
@danking Thanks for your interest! You are correct -- Your best bet is to make your own generator for Here's one to get you started: When junit-quickcheck encounters a theory parameter of type |
|
@pholser Nice! That definitely unblocks me for this. Would it be difficult for me to modify Ctor to do this directly for arbitrary types because the type parameters are lost by the time Ctor sees the type? |
|
@danking Without thinking about it too hard, I believe the benefit-to-effort ratio might be unfavorable to make the changes to
Anyway, I didn't think too hard about the kinds of classes we might use with I don't want to dissuade you from attempting such an enhancement, however. Basically, for a theory parameter marked with Do you think it'd be beneficial to have more documentation around creating custom generators for more complex types? If so, would you create a separate issue for this? Thanks again! I hope you're enjoying using junit-quickcheck. |
|
I certainly am enjoying it! Haskell is my first love and one of my favorite aspects of it was quickcheck. I really appreciate the work you've put into this 😀. I'll try to carve time out this weekend to look into it; I'll come back for more docs if I need them 😉. Thanks for your detailed responses! |
|
I've came across the need of something that is suggested here. My use case is listed here: #239 If Sample code: public static class ManifestBuilder<
Main extends Map<String, String>,
Sections extends Map<String, ? extends Map<String, String>>
> implements Callable<Manifest> {
private final Main main;
private final Sections sections;
public ManifestBuilder(Main main, Sections sections) {
this.main = main;
this.sections = sections;
}
@Override
public Manifest call() {
// actually build the manifest from the components
DefaultManifest m = new DefaultManifest(null);
m.attributes(mainAttributes);
for (Map.Entry<String, HashMap<String, String>> sections : sections.entrySet()) {
m.attributes(sections.getValue(), sections.getKey());
}
return m;
}
}Test code: @Property
public void manifestTheory(
@From(Ctor.class)
GeneratorDescriptors.ManifestBuilder<
@FromField(value = GeneratorDescriptors.class, field = "manifestAttributes")
HashMap<String, String>,
@Size(min=0, max=5) HashMap<@ManifestValue String,
@FromField(value = GeneratorDescriptors.class, field = "manifestAttributes")
HashMap<String, String>>
> builder) {
Manifest manifest = builder.call();
// test manifest
}On top of that it would be great to handle the following (== consider annotations from the type placeholders like public <SimpleAtts extends
@FromField(value = GeneratorDescriptors.class, field = "manifestAttributes")
HashMap<String, String>> void
manifestTheory2(
@From(Ctor.class)
ManifestBuilder<
SimpleAtts,
@Size(min=0, max=6) HashMap<@ManifestValue String, SimpleAtts>
> builder) {
}Unfortunately generic variables do not seem to work 100% (see #240 ) @pholser , what do you think? My example seems to be "self sufficient", and it seems there's no need to implement a generator for That would simplify making complex user-defined objects. |
|
Just to clarify: The price is I have to explicitly call |
|
A bit of a problem for shrinking in So let's consider public static class ManifestBuilder<
MainAttrs extends HashMap<String, String>,
...
> {
public MainAttrs mainAttributes;
...Then |
|
@visi Certainly will investigate. Seems reasonable for |
Can this be made to work?
Currently, with this pom:
I get this error:
which I assume is the result of a failure to correctly handle the instantiated type parameters. :(
I'd be happy to help write a fix or add functionality, but I don't really know where to start.
The text was updated successfully, but these errors were encountered: