What's New > Version 2021.02.01

Enhancing mocking

Release date: Feb 04, 2021

Cover now mocks inputs (arguments and settable class fields) if it increases test coverage.

In order to get more coverage on methods that use objects that are difficult to construct, Diffblue Cover will now mock these objects, when necessary. In the example from apache-tika below, we can now cover the getAnnotationProperty() method by mocking the IdentifiedAnnotation argument which would otherwise require a complex setup. 

Note that Diffblue Cover also adds verify() statements to detect any regression if the mocked methods come to no longer be invoked.

  @Test
  public void testGetAnnotationProperty() {
    // Arrange
    IdentifiedAnnotation identifiedAnnotation = mock(IdentifiedAnnotation.class);
    when(identifiedAnnotation.getBegin()).thenReturn(1);

    // Act and Assert
    assertEquals("1", CTAKESUtils.getAnnotationProperty(identifiedAnnotation,
      CTAKESAnnotationProperty.BEGIN));
    verify(identifiedAnnotation).getBegin();
  }

Feedback

If you have feedback, questions or requests regarding the Diffblue Cover IntelliJ Plugin, please contact us on the community forum. We would love to hear about what is important to you and what you would like to see in upcoming releases.

How do I automatically maintain all of these tests?

Use Diffblue Cover on any CI platform to automatically update your unit tests and catch regressions for every commit - watch this video to learn more.


Full Release Notes

Enhancements

  • CLI: Cover now performs checks to identify project and dependency misconfigurations on projects which use JUnit 4. [Ref: TG-13490]

  • CLI: Cover now logs options passed to dcover at the beginning of its logfile. [Ref: TG-13448]

  • Cover now mocks inputs (arguments and settable class fields) if it increases test coverage. [Ref: TG-13402]

  • IntelliJ Plugin: Performance improvements on macOS, resulting in lower background CPU activity whilst Cover is idle. [Ref: TG-13043]

  • Cover now provides improved guidance when attempting to write tests whilst using a JVM which does not support the JDK used to compile the project. [Ref: TG-11262]

Resolved Issues

  • IntelliJ Plugin: Resolved an issue where tests may not be written if the machine’s CPU is already heavily loaded. [Ref: TG-13559]

  • IntelliJ Plugin: Resolved an issue where, in some circumstances, after updating Cover, attempting to write tests may result in a Couldn't find index for module error. [Ref: TG-13682]

  • CLI: Resolved an issue in the A supported version of JUnit is not available on the classpath error message where spring-test was recommended as a dependency, but it may not provide JUnit. [Ref: TG-13533]

  • CLI: Resolved an issue where Java language compliance level warning messages were not logged to the console if the project’s compliance level is not supported by Cover. [Ref: TG-13520]

  • CLI: Resolved an issue where Running validation command is logged to the console despite --skip-test-validation being passed to dcover. [Ref: TG-13474]

  • CLI: Resolved an issue where terminating dcover, for example via Ctrl+C, does not terminate the Cover service. [Ref: TG-13371]

Known Issues

  • CLI: Windows: creating config.json by outputting --example-config as file causes exceptions. [Ref: TG-11198]

  • CLI: All tests may be discarded in test validation when using --config. [Ref: TG-11475]

  • CLI: dcover clean --working-directory throws an error if --test-output-dir is not provided. [Ref: TG-11665]

  • CLI: dcover fails to generate tests, reporting java.lang.OutOfMemoryError, when analysing projects which spawn a quantity of threads in excess of the operating system’s process thread limit. [Ref: TG-11680]

  • CLI: dcover clean --failing fails when used with a Gradle project. [Ref: TG-11707]

  • CLI: The environment checks that are performed before test generation do not take into account the user command passed by --validation-command. [Ref: TG-13635]