Phg/dto kickoff

[Pgarrett]

What's in the box?

Kickoff for using DTOs instead of stringified json for REST request payloads.
Current limitations:

• it only supports Java as output format language
• supported fields do not include lists nor custom nested objects
• no strategy yet defined for DTOs defined in a spec path (not as a component with a predefined name)
• DTOs not instantiated for to be used in the test payload
• DTO creation should be done before splitting tests, to avoid re-writting and to have complete DTOs

The current implementation is able to handle wanted field scenarios using optionals and jackson:

• field is non null and sent in the payload: {"myKey": "myValue"}/{"myKey": ""}
• field is null and sent in the payload: {"myKey": null}
• field is not sent in the payload: {}

For example, a spec with the following components:

  schemas:
    Person:
      type: object
      properties:
        name:
          type: string
        age:
          type: integer
        address:
          $ref: "#/components/schemas/Address"
      required:
        - name
        - age
        - address
    Address:
      type: object
      properties:
        street:
          type: string
        country:
          type: string
        voted:
          type: boolean
      required:
        - street
        - country

Will generate a class such as:

package dto;

import java.util.Optional;

import com.fasterxml.jackson.annotation.JsonInclude;
import shaded.com.fasterxml.jackson.annotation.JsonProperty;

@JsonInclude(JsonInclude.Include.NON_NULL)
public class Person {

    @JsonProperty("name")
    private Optional<String> name;

    @JsonProperty("age")
    private Optional<Integer> age;

    public Optional<String> getName() {
        return name;
    }
    
    public void setName(String name) {
        this.name = Optional.ofNullable(name);
    }

    public Optional<Integer> getAge() {
        return age;
    }
    
    public void setAge(Integer age) {
        this.age = Optional.ofNullable(age);
    }

}

[arcuri82]

@Pgarrett

a comment regarding

field is empty and sent in the payload: {"myKey": ""}

an empty string in JSON is a valid string. i guess you should make sure to handle the case of null, eg, {"myKey": null}

[arcuri82]

any reason to create a class with constructor, instead of having an object (eg object JavaDtoWriter) with a parametric fun write(...) ?

[Pgarrett]

Actually, two reasons:

1. Hadn't thought about it, I just got writing and my first impulse was to add that information in the constructor.
2. This writer will most likely change. I was thinking this would change into some kind of delegate/decorator. You should actually ask the DtoClass to write itself, which in turn would call the right type of DtoWriter

[arcuri82]

you could move the code here under some utility function in the dto package, and then call it with restSampler.getActionDefinitions() as input

[Pgarrett]

Yes, in the future I was actually thinking of creating a new dedicated class for this, but for starters I added here in the TestSuiteWriter. The class-to-be would actually have to run before tests are split, so as to avoid re-writing or even overwriting DTOs. Then the generated DTOs should be shared with the TestCaseWriter, not sure how yet

[arcuri82]

could use something related to action.getName, and put this as a comment

[Pgarrett]

Could be, yes. We'll most likely come back to this later on

[arcuri82]

you will need to handle the cases of OptionalGene and NullableGene (see how wrapping works), as that will impact what kinds of field types you will need to create. also RegexGene is going to be common. anyway, you will see what things crashing when we activate this feature in the E2E... :)

[Pgarrett]

As a matter of fact, we need more E2E tests! Most e2e tests check on tests generated using GET:

• GET: 103+ matches in 36+ files
• POST: 67 matches in 36 files
• PUT: 6 matches in 5 files

And I looking into the POST tests, some do not have a DTO request payload but instead a response one, or are using simple cases. Looked into that for debugging

[arcuri82]

you might want to use special types for this, and, in the DTOs, throw an IllegalArgumentExcpetion if invalid string. however, for now can leave it as acomment (as we still create invalid strings outside robustness testing, and that is not fixed yet)

[Pgarrett]

Maybe it's something the Gene could answer by itself, something like: gene.getDtoType() and have that answer back. That would also save us from these giant ifs

One other question I have is, for these specific cases of Time and Date, should we in the future handle them with jodatime objects or similar? Or just set them as strings and keep it simple? For a start I think strings are fine, not sure what you had in mind for the future

[arcuri82]

for now we can keep it simple. then we can see feedback from test engineers at VW

[arcuri82]

for now we can keep it simple. then we can see feedback from test engineers at VW