Is DiffblueRules.yaml available for the IntelliJ plugin?

General
1

folks,

i try to get some tests in the context of Http-requests. Diffblue generates me a test which get this input
URI dstUri = Paths.get(System.getProperty(“java.io.tmpdir”), “test.txt”).toUri();
that is a perfectly valid URI - but not in the context of Http-requests.

I read about setting up defined input-data via DiffblueRules.yaml in various folders.
It seems, the IntelliJ plugin doesn’t work with these - there is no indication in the logfile, that it tried to load something from somewhere.
am i missing something?

2

i got it - may this info be of some help to others:

1.) the location of the DiffblueRules.yaml - file matters.
Check for the documentation for the valid places.

2.) yaml - syntax matters (as always). this entry in the DiffblueRules.yaml

java.net.URI:

produces this URI-creation in the generated tests:

    URI dstUri = new URI("https://test.somewhere.org");

instead of the previous, rather unspecific version
URI dstUri = Paths.get(System.getProperty(“java.io.tmpdir”), “test.txt”).toUri();

HTH
dvh

1 Like
3

Hi Dieter,

Thank you for contacting Diffblue Support. The output you get can be improved using Diffblue Rules as you already noticed. We have a tutorial available on YouTube

and the source code can also be downloaded from our GitHub repository

Specifically, the issue you raised is described at 10:20 in the video. The tutorial is recorded using Diffblue Cover CLI but the same works for the IntelliJ plugin

Please follow this short video to see how Diffblue Rules can be used with Diffblue Cover IntelliJ plugin

We hope this helps and we are always happy to provide more guidance otherwise,
Kind Regards,
Cristian.

4

Hello

i was aware of that video - but i took it more as information for corner cases. However, the threshold where this becomes useful and valuable is much lower. For instance, i have lots of String parameters, which are supposed to be numerical (productCodes etc). Diffblue happily creates tests, which stuff a “Hello World” down there. Not much of a problem, some editing can fix this. But with the DiffblueRules-file the initial bunch of tests is somewhat better.
Another application which i see, is defining more useful Date or LocalDate instances. Sometimes you have Dates, which are expected to be in the past, sometimes the Dates are expected to be in the future.
I am confident, my DiffblueRules.yaml will quickly grow.

greetings
dvh

5

Hello again,

This is already possible with Factory Methods. In our video tutorial we have an example which targets File objects and this can be adapted to other Java core classes including those in the java.time package. As you know testing dates can be problematic. Diffblue Cover understands this time-sensitivity and can throw the R031 code, documented here: Working with code R031 | Diffblue Docs
The recommendation is to us Clock. Without a factory class/method and a Diffblue rule, the unit test will use January 1st, 1970 but you can control this date using a setup as the one shown in the screenshot attached.

image
image2838×1132 341 KB

Please let us know if this helps.
Kind regards,
Cristian