Diffblue creates tests which refer into it's belly

Issues
1

good monday morning

Here is something new:
the latest generated tests try to import a file from within the Diffblue-runtime.
As this is not included in the project as a libary, it does not compile.
The ‘b’ is later used to check, if a PrintStream from some object is an instanceof b.
Never had something like that before.
I can upload the testFile to some non-public destination, if needed.

import static org.junit.jupiter.api.Assertions.assertTrue;
import static org.mockito.ArgumentMatchers.eq;
import static org.mockito.ArgumentMatchers.isA;
import static org.mockito.Mockito.anyInt;
import static org.mockito.Mockito.mock;
import static org.mockito.Mockito.verify;
import static org.mockito.Mockito.when;

import basement.cfw.EventLog;
import com.diffblue.cover.commons.h.b;                   <<----- 
import com.fasterxml.jackson.annotation.JsonInclude;
import com.fasterxml.jackson.annotation.JsonSetter;
import com.fasterxml.jackson.annotation.Nulls;
import com.fasterxml.jackson.core.Base64Variant;

    void testNewVehicleServlet() throws MissingResourceException {
        // Arrange and Act
        VehicleServlet actualVehicleServlet = new VehicleServlet();

        // Assert
        EventLog eventLog = actualVehicleServlet.eventLog;
        assertTrue(eventLog.getLogStream() instanceof b);                 <<----- 
        ObjectMapper objectMapper = actualVehicleServlet.om;
        SerializationConfig serializationConfig = objectMapper.getSerializationConfig();
        assertTrue(serializationConfig.getDefaultPrettyPrinter() instanceof DefaultPrettyPrinter);
        JsonFactory factory = objectMapper.getFactory();
        assertTrue(factory instanceof MappingJsonFactory);
        DeserializationConfig deserializationConfig = objectMapper.getDeserializationConfig();
        ContextAttributes attributes = deserializationConfig.getAttributes();
2

the test was generated with plugin version 2024.08.02.
generating test with plugin 2024.08.01 for another, but similar, class did not show this.
That test did not try to access and verify the logStream of the eventLog-object.

hth
dvh

3

Hello @dvholten ,

Thank you for bringing this to our attention and for sharing your observations across the plugin versions, this is most helpful for our team.

We have taken note of this behaviour for version 2024.08.02 and will be looking into this.

We may reach out for any additional information on your experience.

Any further available news on this we will share in due course.

Kind Regards,
Shaun

4

Hello @dvholten

Thank you for your ongoing feedback and for bringing this behaviour to our attention. In our latest package release (2024.10.01), we’ve included an enhancement that addresses the issue you mentioned.

If you have any additional feedback, please don’t hesitate to reach out.

Kind Regards,

1 Like