Spring rest controller and Javax Validation

Hi there,

I’m evaluating yet diffblue for my company (using IntelliJ plugin).
I’ve created and simple spring webmc project in whitch i’ve got a simple Rest Controller with a @GetMapping method to retrieve a restaurant menue.
A menue has a name and is composed with a list of dessert, starter and dishes :

public class Menue{

  private String name;

  private List<Starter> starters



Before serving data to the response of the call, i manualy try to validate that my menu is valid, using Javax.validation annotation on my output DTO, and using

set<ConstraintViolation<Menue>> violations = validator.validate(Menue);

if there are no violation, then the menue is sent as a response to the request, if there are violations, i throw an exception.

  return menue
throw new RuntimeException ...

What i see, is that diffblue correctly create one test with a valid case :

  • Diffblue mocks correcty my controller dependencies even my validator
  • Diffbule initialize correcly the mocks.

Never the less, it seems that diffblue doesn’t generate a case where the validator mock returns one or more violations.
So basicaly a part of my controller is not covered.

My question here, could diffblue analyse javax.validation annotation to generate test cases according to the validation annotations ?

An other point on diffblue, the generated test output differs when

  • a spring annotated service will produce a spring test with mock injection at class level
  • the same service without spring annotation will produce a simple unit test with mock injection at method level
  • the same service where injected beans are not implementing interface will leads to a unit test withtout mocks

I didn’t find on your documentation some chapter explaining how to structure the code to have a specific test generation output. So i’m diving manualy to figure out what is the behaviour of diffblue.

And maybe a last topic : name of the generated test method are not really helpfull : it generates something like : testMethod1, testMethod2, testMethod3 whereas i would exepect something more descriptive like : testMethodWithParamXEmpty, testMethodWithInvalidXparameter …

That said, i’m very pleased about diffblue, the potiential of diffblue is really good.

Have a nice day.


Hi Michael,

Thank you for contacting Diffblue Support and we are glad to hear that you find Diffblue useful in your work. We would answer the three main issues described:

  1. The feedback from our developers is that we don’t currently support javax validation and the tests you obtained are probably due to our general support of Spring. However, this will be discussed internally and we may support javax validation and its annotations in our future releases.

  2. Diffblue Cover writes unit tests which follow the source code logic and maximize the coverage. You don’t need to structure your code in any particular way thinking that this will significantly impact on how unit tests are written, but it is always helpful for greater coverage, to write it in a testable manner. Not all code is testable though, and using the plugin you might have seen these icons Testability and activity icons | Diffblue Docs
    Sometimes the code is not testable because it is not written properly, but here our documentation and output codes help you as you go on with the development. See for example these page Working with code R013 | Diffblue Docs
    In some cases, private fields do not have getters for example and unit tests involving those fields cannot be written, but here we can automatically refactor your code using Cover Refactor: Cover Refactor: Getting Started | Diffblue Docs
    With that said, there are yet also several ways in which you can influence the unit tests written by Diffblue Cover, or rather decide the parameters which must be used in your unit tests. Custom Inputs: Customizing test inputs | Diffblue Docs and Cover Replay: Cover Replay: Getting Started (Windows) | Diffblue Docs These are features are however available with the commandline (CLI) version of Diffblue Cover, for which you can have a trial license.

  3. We are aware that naming unit test methods is not done in the most self-describing manner but for now it is the most efficient way. When Diffblue Cover writes unit tests through thousands of iterations, memory and execution time is efficiently allocated to the critical part of the product which carries out fuzzing and logic validation such that all of our tests run and pass. Driving the same process only for naming methods would require extra resources leading to lower performance, while incrementing the suffix number costs nothing. Although the method names share the same root, they contain different assertions which sum up to maximize coverage, and as long as all of them run and pass they validate your codebase safely. However, suggestions are always welcomed and might be included in the future. Do you have a naming scheme in mind, based on your experience with Diffblue Cover?

Are you creating just a few tests for the evaluation or would you need to create unit tests for a complete module or multi-module project? If so, our CLI version would be more suitable than the plugin, which you are making good use of. The CLI version, although works on the same engine, is designed to ease test creation at scale with many useful options at the command line.

We are looking forward to assisting you in getting the most of our products.
Kind Regards.