In this tutorial we show both the input source code, and the tests written by Diffblue Cover, for code of varied complexity, accompanied by a detailed narrative to help you further understand tests created by Diffblue Cover.
This is a simple example of Spring Service source code with a trivial getter. Cover can write a Spring Boot test for the getter in a service provider by inlining Arrange, Act, and Assert.
Source
This is a class that contains two methods to upload and download a file to/from an Amazon S3 bucket. As the Amazon S3 bucket is a cloud storage mechanism, the test for this class/methods requires dependency injection. Cover can mock these types of dependencies and tests the downloadFileFromBucket method by asserting the expected S3Object and the downloaded S3Object using the method.
This example returns time in a different format. Cover writes a test to assert date and time that is not dependent on operating system or local time zones.
In this example, Cover writes two tests to cover each pathway through the conditional - a test which adds 10 to the balance and asserts the new balance should be 20 and a second test where the account is closed.
This example code has three branches - Cover covers 100% of branches and creates three tests for three cases using existing enum values.
Diffblue Cover CLI deliberately does not test trivial methods such as getters, setters, constructors and factory methods to avoid creating large quantities of noisy tests that do not contribute to overall coverage. There isn't a benefit to be gained from testing these trivial methods directly as, for example, getters and setters simply access attributes so there is no actual logic to be tested. Similarly, constructors and factory methods also contain little or no logic. If Diffblue Cover CLI did test such methods directly, a minor coverage increase might be gained, but this "improvement" would be meaningless in terms of improving code quality.