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 initialized 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:

• Click or select Write Tests - Diffblue Cover will analyze 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 provided is disabled, just like any other partial test that is not expected to pass.

• Right-click and select Write Skeleton Tests - Diffblue Cover won't analyze your code to write complete tests but instead will only create a single skeleton test for the method. In this case, the skeleton test provided is not disabled as it's 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
}

This skeleton test serves as a helpful illustration of the output code, allowing you to play with your code and better understand why testing the method is difficult, and what could be changed to make it easier. In other cases you will know a way of obtaining an instance to test with, in which case you are well placed to complete the test by hand, choosing useful values for the variables and adding relevant assertions. Alternatively, you may want to "teach" Diffblue Cover how to create useful instances via Custom Inputs.