looking at some generated tests i found a call System.getProperty() without using the result (line80).
The javadoc for that method mentions, that a call to the SecurityManager is done and the System.properties-store is filled. It would make sense, to issue such a call for these effects.
However, in another test (line 95) the System.getProperty(…) is used to lookup some pathName - and then use the result.
In line96, another call System.getProperty(…) is done - without using the result.
This raises the question : are you sure, that your calls to System.getProperty() always make sense?
thanks for quick reply - however, i have some doubts.
there is no mention of properties in my code. Diffblue came up with this. It seems to have innovative ways to get values from somewhere, when needed.
iirc, it imported some Swing-constant, when it needed a -1.
So, when a Path was needed, it asked System.getProperty(“java.io.tmpdir”) - which is a reasonable way to get a name of a temp-file.
My question was about the purpose of the getProperty() - calls in lines 80 and 96.
that’s true, I was mislead. It seems that your method uses a Path reference which needs a file from the disk. In the first instance Diffblue Cover provides a generic location for that file. It gives it a name test.txt and locates it in your temporary folder depending on the operating system in use, hence System.getProperty(“java.io.tmpdir”). Of course such file doesn’t exist and depending on the method logic you get the assertThrows(). However, if you want to test the method on a real file please watch this tutorial
at 01:29. As with .properties files, usual .txt files can be supplied using Diffblue rules. Please try and let us know how it goes.
Hi Dieter, After speaking with Engineering I can confirm that the two unassigned statements are a benign bug which will be fixed. It’s a kind of leak from the internal machinery of Diffblue Cover. However, issues like this one are quite rare.
