Question

I am currently working on increasing the test coverage of a project, it is around 93% and I am working my way towards 100%.

I noticed that one of the blocks that are not being covered is the main method and it looks like this:

public static void main(String[] args) {
    SpringApplication.run(Application.class, args);
}

Even though the application has over 90 tests, and some with the @SpringBootTest annotation, this main method is still not covered.

Should I worry about this and make sure I get a 100% coverage? Or am I being too much of a perfectionist and certain things are just not worth to test, like the example above?

Why is the code above not being ran through the tests? Do I need to explicitly call the main method for it to be ran? I was expecting it to be called when the application starts up.

Answer 1

You don't do unit testing for the fun of it. Therefore you also look at coverage for a distinct purpose.

The purpose is: building software that has the required quality. You don't measure things and set goals because you can, but because the process of doing so helps improving the quality of your product.

Thus: when you can clearly define the additional value of testing such code, then it is worth investing time here. Especially because investing time for this costs energy that you can't use for other things.

Long story short: sit down with the people in your team and assess the return of investment that such tests (and beyond that goals like 100 percent coverage) and then follow the outcome of that. In other words: don't look (too much) for advice from strangers to determine your own priorities. You know your product, we don't.

Answer 2

代码覆盖率本身是无用的指标。它没有告诉您如何涵盖您的代码/要求。它只能指向未完全覆盖的地方。通过可怕的测试实际检查任何东西都很容易达到100％。

此外 - 如果人们接触到指标，他们会尽一切努力改善这些指标。而不是做有用的东西。所以（至少在我的实践中）在引入这些指标后，人们开始编写更糟糕的测试更糟糕的测试（我不在这里讨论线路覆盖）。

如果您真的关心测试质量，您应该进行代码审查。如果您喜欢指标并希望坚持使用线/分支覆盖率，至少还要引入变异测试。

所以最后：不，你不应该尝试达到100％的线路或分支覆盖范围。

Answer 3

Should I aim to 100% test coverage[...]?

yes.

But you should not cover lines of code, but requirements.

Your automated tests (unit test, module tests and acceptance tests) should cover 100% of the requirements fixed in the project documentation.

The best way to achieve that is test driven development.

TDD will not lead to 100% coverage, but it creates a trustworthy safety net which is much more valuable as a certain amount of measurable test coverage.

Answer 4

我应该100％瞄准吗？是的，总是！。但是，如果说任何超过90％的东西都被认为是好的。在所有情况下可能无法达到100％。

谈论＆＃34;主要方法＆＃34;，因为它仅用于启动弹簧启动应用程序并且不包含任何功能，您可以简单地从包含在您的pom中的主要方法中排除包含主要方法的类.xml文件使用属性标记内的以下代码行：

 <sonar.coverage.exclusions>
  **/com/example/test/MainApplication.java
</sonar.coverage.exclusions>

Answer 5

我同意我们应该争取100％的覆盖率。 valid argument有一个main方法不是生成的代码，可能您可以在该方法中编写一些额外的逻辑。因此，您应该编写一个涵盖该测试的测试。

对于用于引导Spring Boot应用程序的main方法的特定示例，我可以提出以下简洁的JUnit 5测试

import static org.junit.jupiter.api.Assertions.assertDoesNotThrow;
import org.junit.jupiter.api.Test;

class ApplicationTest {

  @Test
  void main() {
    assertDoesNotThrow(() -> Application.main(new String[]{}));
  }

}

Should I aim for 100% test coverage on Jacoco?

5 个答案: