Produced tests are not testing what is esencial in method

Ideas
1

Hi

I am evaluating diffBlue. We have a simple API class with update method that take DTO and update JPA entity fields.

I am expecting a unit test that would compare that DTO field values are copied over to an entity fields.

EndpointApi.java:

@Override
public Endpoint update(EndpointDto endpointDto) throws MeveoApiException, BusinessException {

    Endpoint endpoint = endpointService.findByCode(endpointDto.getCode());
    if (endpoint == null) {
        throw new EntityDoesNotExistsException(Endpoint.class, endpointDto.getCode());
    }

    endpoint = fromDto(endpointDto, endpoint);
    endpoint = endpointService.update(endpoint);

    return endpoint;
}

Unfortunatelly a generated unit test mocks endpointService.update(endpoint) result and compares that it matches the return value of EndpointApi.update().
Completely useless unit test.

I was expecting that unit test would capture endpointService.update(endpoint) argument and compare its values to DTO.

Ok, so I thought maybe its too complicated, made fromDTO a public method, so unit tests would be generated for it. Well… not much more exciting - it does not compare all fields.

I am attaching a generated unit test file. Any ideas what to change so that fromDTO method would receive much more emphasis?

fromDto() contains quite simple entity.field = dto.field type of assignments

EndpointApiDiffblueTest2.java (116.4 KB)

Thanks

2

Hello @andrius.karpavicius ,

Thank you for getting in touch and for exploring Diffblue Cover.

Sharing the test and example code snippet is appreciated, this helps provide useful context to the behaviour you are encountering.

We are in the process of reviewing this and will provide you with our feedback/suggestions very soon.

Kind Regards,
Shaun

3

Hello @andrius.karpavicius ,

Thank you for your patience while our team reviewed the use case and behaviour you experienced.

Cover includes functionality that can be applied to adjust and refine the behaviour of test generation. Using the information you shared, our team compiled a basic DTO example and applied two approaches to improve the inputs for Cover. This resulted in a generated test that I believe aligns more closely with your desired output.

I’ve attached a copy of the example, which includes the generated test. Below are the approaches applied:

  1. Creation of a diffblueRules.yaml file.
  • Further information on this custom input file can be found on our documentation website HERE.
  • This file allows additional configuration to enhance the inputs Cover considers during test generation.
  • In this instance, a factory option was used, pointing to an additional class created to define settings for the EndpointDto class.
  1. Incorporation of annotation for the EndpointService class.
  • More details on annotation options can be found on our documentation website HERE.
  • The annotation provides Cover with additional instructions during test generation.
  • In this case, the annotation specifies that certain activity—namely, the EndpointService class—should not be mocked.

This is, of course, a basic example. There may be additional considerations for your project, especially if it is larger and more complex. However, I hope this provides the insight and direction you were looking for.

Please don’t hesitate to reach out if you have any further questions or encounter any challenges.

Replication1.zip (41.1 KB)

Kind Regards,
Shaun