Comment on page
Creating skeleton tests
What are skeleton tests, how to get them and how can they help when using Diffblue Cover?
Skeleton tests simply consist of a call to the method under test, with all variables initialised to
null or zero, and some comments reminding the user to better populate the "arrange" section and come up with some assertions. They are intended as a helpful starting point for users to write their own tests.There are two ways of obtaining a skeleton test for a method in Diffblue Cover:
- When left-clicking on, or selecting
Write Testswhen right-clicking onor code: Diffblue Cover will analyse the method and related classes to write one or more complete tests (or partial tests if this is enabled) exploring the coverage that can be accessed from each method under test. Sometimes this approach is unsuccessful and rather than give you nothing, Diffblue Cover falls back to offering a single skeleton test for the method instead. In this case, the skeleton test arrives disabled just like any other partial test that is not expected to pass. - When selecting
Write Skeleton Testswhen right-clicking onor code: Diffblue Cover won't analyse your code to write complete tests but instead will only create a single skeleton test for the method. In this case, the skeleton test does not arrive disabled as it is assumed that you will complete the test by hand immediately. This can be useful when you need to write a test reproducing a specific scenario and just want some help getting started.
Skeleton tests are intentionally written with all available comments to aid readability, and minimal inlining to ease editing, which means that all test formatting options will be superseded.
For example, consider the method in the following inner class in an outer class,
DatabaseDao:public class DatabaseDao {
public static class Inner {
private Inner() {
}
public void myMethod(Inner inner) {
}
}
}
Diffblue Cover is unable to test this by default as there doesn't appear to be a way of creating an instance of
Inner on which to call myMethod(Inner), and so this results in an R008 output code with some explanation why a full test could not be written. Rather than provide just the output code, Diffblue Cover will offer a skeleton test for the method as follows:/**
* Method under test: {@link DatabaseDao.Inner#myMethod(DatabaseDao.Inner)}
*/
@Test
@Disabled("TODO: Complete this test")
void testInnerMyMethod() {
// TODO: Complete this test.
// Reason: R008 Failed to instantiate class under test.
// Diffblue Cover was unable to construct an instance of DatabaseDao.Inner.
// Add a package-visible constructor or a factory method for the class under test.
// If such a method is already present but Diffblue Cover does not find it, it can
// be specified using custom rules for inputs:
// https://docs.diffblue.com/knowledge-base/cli/custom-inputs/
// This can happen because the factory method takes arguments, throws, returns null
// or returns a subtype.
// See https://diff.blue/R008
// Arrange
// TODO: Populate arranged inputs
DatabaseDao.Inner inner = null;
DatabaseDao.Inner inner1 = null;
// Act
inner.myMethod(inner1);
// Assert
// TODO: Add assertions on result
}
For some developers this skeleton test will serve as a helpful illustration of the output code, allowing them to play with their code and better understand why testing the method is hard, and what could be changed to make it easier. In other cases the developer will know a way of obtaining an instance to test with, in which case they are well placed to either complete the test by hand, choosing useful values for the variables and adding relevant assertions. Alternatively, the user might want to teach Diffblue Cover how to create useful instances via Custom Inputs.
Last modified 2mo ago