reusing models

[adrian-herscu]

Feature description

Consider having a model defined in a super class.
Is it possible to reuse it in subclasses?

class A {
  public String field1;

  public static Model<? extends A> model() {
    return ... model of A;
  }
}

class B extends A {
  ... additional fields...
  public static Model<? extends A> model() {
    return ... // how to reuse A.model() here to produce a Model<B>?
  }

[armandino]

Could you provide more details on what you're trying to achieve? What would be the difference between Model<A> in class A and B?

[adrian-herscu]

Could you provide more details on what you're trying to achieve? What would be the difference between Model<A> in class A and B?

Simply want to reuse the rules defined for class A by adding additional rules for sub-class B.
Class A may have 20+ fields, hence may require a matching number of rules.
Then comes sub-class B adding more fields which require more rules.
Currently, I couldn't find a way of reusing the rules of class A in subclasses.
Maybe I am missing something?

[adrian-herscu]

Tried:

    @ToString
    static class A {
        public String f1;

        static <T extends A> Model<T> model(Class<T> clazz) {
            return Instancio.of(clazz)
                .set(field("f1"), "kuku")
                .toModel();
        }
    }

    @ToString(callSuper = true)
    static class B extends A {
        public String f2;

        static <T extends A> Model<T> model(Class<T> clazz) {
            // ISSUE not sure how or even if possible to remove this cast
            return (Model<T>) Instancio.of(A.model(B.class))
                .set(field("f2"), "kuku")
                .toModel();
        }
    }

    @Test
    public void shouldGenerateB() {
        // ISSUE fails with invalid field 'f1' for class B
        Instancio.of(B.model(B.class))
            .stream()
            .limit(1)
            .forEach(b -> log.debug(b.toString()));
    }

[armandino]

Got it, thank you for the clarification and the example. Your example should work. You just need to specify the class explicitly when using the field selector: field(B.class, "f2") instead of field("f2").

I was writing another example before I saw your second comment:

class PojoA {
    String foo;

    String getFoo() { return foo; }
}

class PojoB extends PojoA {
    String bar;

    String getBar() { return bar; }
}

static <T extends PojoA> Model<T> model(Class<T> klass) {
    return Instancio.of(klass)
            .set(field(PojoA::getFoo), "foo")
            .toModel();
}

// Example
Model<PojoA> modelA = model(PojoA.class);

Model<PojoB> modelB = Instancio.of(model(PojoB.class))
    .set(field(PojoB::getBar), "bar")
    .toModel();


PojoA pojoA = Instancio.create(modelA);
PojoB pojoB = Instancio.create(modelB);

// Output:
// PojoA(foo=foo)
// PojoB(foo=foo, bar=bar)

[adrian-herscu]

Any idea how to remove this down cast?

static <T extends A> Model<T> model(Class<T> clazz) {
            return (Model<T>) Instancio.of(A.model(B.class))
                .set(field("f2"), "kuku")
                .toModel();
        }

[adrian-herscu]

Seems that I have something workable, but still wondering if this is best approach for achieving reuse.

How different Instancio will behave, if the model was to be defined on the C class and specify its rules on descendat members?

In my real project I have about 30-40 classes, each containing 10+ fields, and just trying to come up with an workable design. Any suggestions?

    @ToString
    @EqualsAndHashCode
    public static class A {
        public String f1;

        static <T extends A> Model<T> model(Class<T> clazz) {
            return Instancio.of(clazz)
                .generate(field(A.class, "f1"), oneOf("foo", "bar"))
                .toModel();
        }
    }

    @ToString(callSuper = true)
    @EqualsAndHashCode(callSuper = true)
    public static class B extends A {
        public String f2;

        static Model<B> model() {
            return Instancio.of(A.model(B.class))
                .set(field("f2"), "kuku")
                .toModel();
        }
    }

    @ToString
    @EqualsAndHashCode
    static class C {
        B      b;
        String f3;

        static Model<C> model() {
            return Instancio.of(C.class)
                .supply(field("b"), () -> Instancio.of(B.model()).create())
                .set(field("f3"), "muku")
                .toModel();
        }
    }

    @Test
    public void shouldGenerateC() {
        Instancio.of(C.model())
            .stream()
            .distinct()
            .limit(2)
            .forEach(b -> log.debug(b.toString()));
    }

logs:

10:55:07.411 [DEBUG] [main ] [1]: InstancioSelfTests - InstancioSelfTests.C(b=InstancioSelfTests.B(super=InstancioSelfTests.A(f1=bar), f2=kuku), f3=muku)
10:55:07.415 [DEBUG] [main ] [1]: InstancioSelfTests - InstancioSelfTests.C(b=InstancioSelfTests.B(super=InstancioSelfTests.A(f1=foo), f2=kuku), f3=muku)

[armandino]

I think there are two options. One is to use models, as in your example:

static <T extends A> Model<T> model(Class<T> clazz) { ... }

If the classes being created are unrelated (e.g. C does not extend A or B), then you could also do modify the method signature to make it more generic:

static <T> Model<T> model(Class<T> clazz) { ... }

Then you can create A, B or C using this model. However, the model can only work on fields that are common to all classes. Otherwise you'll get an "unused selector" error.

Another option is to create custom generators for your domain classes. You can find a sample implementation in this repository (see the generator-provider-sample sample):

• https://github.com/instancio/instancio-samples

Documentation:

• https://www.instancio.org/user-guide/#instancio-service-provider-interface

[adrian-herscu]

Usually, for testing we need to construct some object tree , like:

SomeRequest
/          \
Data    MoreData
              \
              EvenMoreData

It can be an OrderRequest containing a Payment, a Shipment which further contains an Address, and so on.
(each of these items being defined by a class)

I envisioned two possible approaches:

1. hold the generation rules for each class in separation -- define a static method model, and maybe another for invalidModel, for each of these classes, and then reuse them by calling, such as SomeRequest#model calls MoreData#model and so on
2. hold the generation rules in one place -- define one static SomeRequest::model method which deals with all fields in SomeRequest and its contained objects

I thought that the 2nd approach would quickly become unmaintainable, because any time a field is added/deleted or its semantics are changed, then the SomeRequest::model method should be updated to reflect that change, hence the change is no longer local but always require touching two classes. Not only this, but the SomeRequest class now becomes some kind of "god" class, which has to deal with the dependendencies and limitations of all other composing objects.

Moreover, Data, or any other composing classes, may be used to compose other classes. Hence going with the 2nd approach would now require duplication of generation rules, for all classes reused in compositions.

Perhaps I am missing something? Are there any other approaches?

In the documentation it looks like the 2nd approach is suggested (https://www.instancio.org/user-guide/#selector-depth). But again, even with the simple object tree used throughout the documentation:

class Person {
    String name;
    Address homeAddress;
    Address workAddress;
}

class Address {
    String street;
    String city;
    List<Phone> phoneNumbers;
}

class Phone {
    String areaCode;
    String number;
}

a Bussiness also can have an Address and a Person may have a mobile Phone which doesn't necessarily imply he has an Address (maybe a NomadPerson).

[armandino]

In addition to the two options above, you can also define custom generators (see #774 (comment)). For example, the generator could be used to create valid objects. If the generator is registered via the SPI, then you could do:

Phone phone = Instancio.create(Phone.class);

// Sample output: Phone[areaCode=453, number=3479148]

to create an invalid Phone you could then customise the object:

Phone phone = Instancio.of(Phone.class)
    .set(field(Phone::getNumber), "invalid")
    .create();

// Sample output: Phone[areaCode=523, number=invalid]

Usually, I prefer option 2 from your comment above, though I agree that it can get complex if there are many nested classes and collections. I think the approach would depend on your testing requirements. E.g. do you need to create many objects in different states? customise deeply-nested properties and collections? etc. If you create a sample Github repo with some domain classes and specific test cases I could take a look to see what can be done.

[adrian-herscu]

Found https://www.instancio.org/user-guide/#generatorprovider
and thinking about implementing my own generator.
I see that the generator has full access to each matched field via Node object. Then, I assume I can build my own to take into account the relevant annotations.
What do you think?

My reasoning is that if current generators can take these annotations into account to generate random values, then I can make my own to generate limits and out-of-limits.

[armandino]

I'm not sure if the generator provider SPI is a good approach for generating invalid data. The main use case for the SPI is to automatically pick up generators based on type or field. It can probably be done, but you may need to experiment to see if it works...

[adrian-herscu]

I'm not sure if the generator provider SPI is a good approach for generating invalid data. The main use case for the SPI is to automatically
pick up generators based on type or field. It can probably be done, but you may need to experiment to see if it works...

I have another idea...
Maybe it could be implemented by specifying some additional settings in the spirit of Keys.BEAN_VALIDATION_ENABLED, such as:

• GENERATE_UPPER_LIMITS
• GENERATE_LOWER_LIMITS
• GENERATE_OUT_OF_LIMITS
  Then have the current generator(s), altered somehow to support these.
  I know, there are special cases, such as regex bound fields which will need special handling.
  But let's leave these to later.
  What do you think?

[armandino]

That could work. Instancio does support custom keys. See for example https://github.com/Mobe91/instancio-jpa

I'd suggest forking the project to add such capability.

[adrian-herscu]

Did that :)
https://github.com/adrian-herscu/instancio-experiment

Looking into it for several hours... Still, looks like a mystery. Can you please help me understand the basic architecture/concepts? How can I implement my own generator, or otherwise alter the behavior of it?