连续UnitTest的七个规则

介绍

您是否在项目上编写单元测试？ 是否每次都运行单元测试？

我完全认为编写UnitTest和编写“连续的” UnitTest是同一回事。 但这是不同的。

几乎工程师知道UnitTest很重要。 因此，他们编写了UnitTest。 但是我看到这样的UnitTest一次又一次被废除。 为什么？ 由于它们非常慢，因此难以维护，并且已损坏。

连续UnitTest需要满足一些要求。 您可以通过以下规则满足此要求。

• 始终运行保持可移植性保持重复性避免进行RDB，仿真等慢速测试不要用眼睛一个单元测试，一个测试的观点使用可读的名称

在本文中，我将解释这些规则。 我解释基于Java，Maven，JUnit的情况。 但是您可以申请其他语言。

七个规则

始终运行

这条规则是最重要的。 每次构建代码时，都应每次运行UnitTest。

不要使用-Dmaven.test.skip = true!! 请...

如果您始终可以运行所有单元测试，则它们是连续单元测试代码。 但是，如果您做不到，则需要对其进行修改。

保持可移植性

可移植性很重要 单元测试不仅可以在您的PC上运行，而且还可以在其他环境上运行。 其他环境是同事的PC，CI环境以及将来的PC。

为了实现可移植性，您只需要在项目目录下使用。 你不应该使用/ var / foobar和D：\ foobar as test data directory和so on。 请在下使用目标目录或src / test / resources /。

保持重复性

可移植性对。。。很重要一直运行。 Your code should be ran without any manual operations like a removing test data and so on。

通常，此类初始化或清除代码应在设定要么拆除。

避免进行RDB，仿真等慢速测试

您应避免使用RDB测试之类的慢速测试，而应使用模拟器。 这样的测试非常有用。 你应该去做 但是，这是集成测试。

JUnit还支持集成测试。 您可以通过DBUnit使用实际的DB。 您可以使用arquillian。 今天，您甚至可以使用Docker。

我喜欢它。 但是这些测试很慢。 如果测试很慢，则不会每次都运行所有UnitTest。

因此，您应该将“慢速测试”之类的测试分开。 我建议做一个慢速测试个人资料或使用Maven的集成测试阶段。 And you can ran it when build on CI environment or before commit。

不要用眼睛

不要用眼睛测试UnitTest！

UnitTest应该自动检查断言。 您不应该用眼睛检查日志，标准输出，文件输出等。 请使用assertThat，assertEquals等。 这是JUnit的角色。

Maybe following article helps you.
How do you write "Production Code" for UnitTest?

一个单元测试，一个单元测试，一个测试的观点

每次测试应只检查一个观点。 如果一个测试用例有很多观点，那么很难检查哪个测试失败了。

这不是手动测试。 您无需降低测试操作成本。 您只能从一个角度进行测试。

每种方法请仅避免一个测试用例。

使用可读的名称

请使用可读的名称。 你应该避免像测试001，测试002，测试003... 因为任何人都无法理解其方法的期望。

命名和生产代码一样重要。

也许BDD风格对您有很大帮助。 您应该使用方法名称，条件和期望作为测试名称。

摘要

我认为几乎统治并不困难。 也许许多人认为几乎规则是很自然的。 您甚至可能认为这是不必要的，因为这是常识。

但重要的是要明确规则。

特别是，许多人不会将UnitTest和IntegrationTest分开。 JUnit测试就像JUnit测试一样进行管理。 这样不好。

我相信简单的规则可以支持顺畅的沟通！

骇客入侵！

from: https://dev.to//koduki/the-seven-rules-for-continuous-unittest-4j9l