I am playing around with the diffblue cover plugin for the first time and tried to let it generate tests for a single Spring-Service-method.
Output in the idea-window is:
Tests written: 0
Cover was unable to write any tests for the reasons listed below.
Change what sort of tests Cover writes in Change Settings.
Methods without tests: 1
Diffblue AI was unable to find a test: 1
Thank you for reaching out and uploading the log files - I’ve had a look with our engineers and it is likely there is a bug in Cover that occurs whilst dealing with an open source library you are using (Apache Lucene). To help us recreate the issue; are you please able to share the code that triggered this?
What exactly do you want to see?
Only the method I tried to generate tests for? That would be easy.
Or do you want to see the whole environment around the method? Question here is how far this should go? This could be difficult to reach…
Maybe it’s easier you ask some specific questions or you offer suggestions what I can try to circle the problem for you.
The method should be enough, or the class is ideal if you’re able to share it as it also seems from the log file you shared that the code is complex, so any further information would be useful to us.
In any case, I will also keep looking internally if there is a way to work around this in the meantime.
The class is this: PatientHauptArztrolleUndBehandlungsortService.java (4.6 KB)
Nothing really complex…
The parameters which deal with apache lucene in other use cases are ‘Patient’ and ‘Behandlungsort’, some Attributes of this types are lucene-indexed.
In the meantime I tried to remove the parameters from the parameter-list and introduced them as local variables. By this way the tests were generated. After this I have to adjust the generated test back to the real conditions. This is only a workaround.
I hope this helps you to find a solution so the workaround above is not needed in future.
Any further questions are welcome.
The output code, R024, means that an internal process stopped unexpectedly. This is often due to a limitation of resources, in particular Java heap space. In this case, it looks reasonable at 4GB but it could be a factor. Information for setting this value for the JVM in IntelliJ can be found in the Diffblue documentation under Memory Management.
Please also check that the resources on the system in questions match the prerequisites in the Diffblue documentation.
I notice that the Java version being used is 22.0.1, which is not currently a supported release for Diffblue Cover (this will follow in the near future). It is possible this could have an impact, so I’d suggest trying an earlier supported version, such as Java 21.
After some time I tried again to generate tests for the usecase mentioned in my initial post without my workaround.
Still no tests are generated.
It seems the issue is different now but even not the same as the other issue which was posted on this thread in the meantime.
Logs for the current situation are added…
I also tried to generate unit tests for some other methods in other classes (Spring services). Here, too, only a minimal test framework was generated but no working test.
-The output in idea showed
R013 - No inputs found that don’t throw a trivial exception: 1
-A comment like this was inserted in the test:
// TODO: Diffblue Cover was only able to create a partial test for this method:
// Reason: No inputs found that don't throw a trivial exception.
// Diffblue Cover tried to run the arrange/act section, but the method under
// test threw
// java.lang.NullPointerException: Cannot invoke "de.t2med.telematik.online.services.TelematikIdentityProviderConsentService.consentShown(String, de.t2med.telematik.mandant.entities.TelematikMandantEntity)" because "this.consentService" is null
// at de.t2med.telematik.online.services.TelematikIdentityProviderService.getAccessToken(TelematikIdentityProviderService.java:177)
// See https://diff.blue/R013 to resolve this issue.
Thanks for getting back to us with this feedback, on the post there are 2 separate issues;
R013’s seen on other classes - I would recommend creating a new forum thread, and we can help you there.
R083 + E062 - relating to the original post raised for the PatientHauptArztrolleUndBehandlungsortService.insert class
-It’s great to see we have much more useful logging now with these new output codes, I will investigate the log files along with the original class you sent (I assume this hasn’t changed significantly), and will get back you.
I have spoken internally to our engineers who had a look into this issue, this is what we have come up with as suggested actions to resolve this case:
R083:
It’s possible there is no public constructor or factory method for creating the ObjectId. If there is, it is likely that the problem communicating between the client and the service. The ObjectId might be needed for the Patient, Arztrolle or Behandlungsort in the method arguments.
Therefore, we recommend to provide an easy way of creating them, this should avoid the need to make ObjectIds. This can be done by adding a factory method to create the objects for testing only (maybe with @VisibleForTesting), then use our Custom Inputs feature, specifically the factory rule to use that method, then you won’t have to change the MUTs.
E062:
After investigating it appears E062 is different from the R083 as here is the service shutting down. Do you always get this E062 output code in every run?
If this only happened once, as you got tests it wasn’t a problem. If it is occurring in every run, then it is worth us diving deeper in a different thread.
R083:
Yes, the ObjectId class has no public constructor. If I add such a constructor, the messages no longer appear in the log.
Regarding the suggested variant: Isn’t the ‘Custom Inputs feature’ only available in the CLI version? I’m currently only using the community version.
E062:
This error occurs every time I generate a test for the specific method. It seems to have something to do with the ‘Flight Recorder’.
Referring to the error ‘R013 - No inputs found that don’t throw a trivial exception: 1’ that I recently mentioned in this thread: It seems that test generation for Spring beans only works if these beans are initialized using ‘constructor injection’. It doesn’t seem to work using field injection. Is there any way to set how the beans are initialized (i.e. constructor or field injection)?
Yes, the Custom Inputs feature is available for all users, as well as Custom Test Setup. Cover’s core engine is the same between the Cover CLI and IntelliJ plugin. In both uses, it will detect the presence of a DiffblueRules.yml, which is the file used to declare the Custom Inputs.
Can you set how the beans are initialized (i.e. constructor or field injection)?
Not at the moment. The constructor injection and field injection should be interchangeable. Also, it is worth checking if you have any fields are final.
If they are; it means that they must be initialized either at the time of declaration or within the constructor of the class. Since final fields cannot be modified after their initial assignment, this restriction would impact how dependency injection works.
You could try to remove final if possible, then field injection may work.
For the ‘constructor or field injection’ suggestion:
I checked the classes for the modifiers of the @Autowired-fields. They are only ‘package private’, not ‘final’ and not even ‘final private’. Also I tried to make them ‘public’. But it did not help. I have to add a constructor to the CUT with the members to be constructor-injected.
or you offer suggestions what I can try to circle the problem for you.