5

如果您正在测试如下所示的计数函数，那么在一个函数中为函数测试多个事物与为每个测试都有一个测试函数是“正确的”还是“错误的”？

function testGetKeywordCount() {
    $tester = $this -> getDatabaseTester($this -> CompleteDataFile);
    $tester -> onSetUp();

    $KeywordID = 0;
    $this -> setExpectedException('InvalidArgumentException');
    $this -> keyword -> getKeywordCount($KeywordID,'Active');

    $KeywordID = 1;
    $this -> setExpectedException('InvalidArgumentException');
    $this -> keyword -> getKeywordCount($KeywordID,'InvalidStatus');

    $this -> assertEquals(1, $this -> keyword -> getKeywordCount($KeywordID,'Active'));

    $tester -> onTearDown();
}
4

6 回答 6

4

您应该有多个测试功能，每个测试自己的条件。这样，无需调试就更容易发现故障。

于 2009-04-17T21:03:45.617 回答
4

每个场景都有一个测试用例是理想的。但是，在某些情况下，在一个测试用例中测试多个场景会更方便（从实现工作的角度来看是有效的）。如果您使用的框架不会在第一次失败时停止，而是尝试在测试用例中尽可能多地执行，那么该框架适用于每个测试用例的多个场景。

我更喜欢在单元测试上花费尽可能少的时间，并且在那段时间内仍然获得尽可能多的覆盖率。

最后，如何实现单元测试并不重要，重要的是这些测试的正确性。

于 2009-04-17T21:08:25.450 回答
1

测试框架并不总是值得您努力遵循每个测试规则的一个断言。

其中之一是RSpec for Ruby，它允许您设置嵌套示例组。例如：

  • 用户
    • 没有密码
      • 是无效的
      • 抛出异常
    • 有密码
      • 以前用过的
        • 是无效的
        • 抛出异常
        • 出行安全警告
      • 以前没用过的
        • 已验证
        • 重定向到帐户页面

通过逐步构建场景并测试每个步骤，更容易坚持每个测试方法一个断言。它还可以更轻松地发现未经测试的场景。

于 2009-04-17T22:28:06.757 回答
1

将断言分成两个单独的测试的一个论点是，如果其中一个断言失败，您将得到一个失败；如果两个断言都失败，你会得到两个失败。

此外，通过使每个测试的名称尽可能具有暗示性，当出现问题时，您将获得额外的线索。

于 2009-06-22T18:23:01.613 回答
0

我不会在上面的示例代码中谈论单元测试。
您的示例更像是一个自动化功能测试，它测试功能流。

但是在这种情况下，可以有多个断言。

只需确保 2 个断言不是一个接一个。

不好的例子 

public void ValidateRulesEntry_Valid_ValidConditionsFromFile()
{
    string condition = "Target.HasValue";
    string returnMessage;

    bool successFul = CodeParserTryParseCondition(condition, out returnMessage);


    Assert.IsTrue(successFul);
    Assert.IsFalse(string.IsNullOrEmpty(returnMessage));
    Assert.IsTrue(returnMessage == "OK");

}

最后的 2 个断言依赖于第一个断言 IsTrue(successFul)。

想一想：如果测试失败 --> 告诉我为什么（不查看调试输出）

于 2009-05-20T13:19:55.820 回答
0

这是一个有不同答案的问题，具体取决于您问的人，主要取决于他/她的个人意见或专业经验。一些极端理论的人会告诉你，在测试中拥有多个断言是一种至高无上的罪过，你将永远注定要失败。但是其他有更多实际经验的人可能会告诉你，在某些情况下，每次测试有 10 甚至 50 个断言是非常好的。

那么，谁是对的？

面对这种困境时，我总是尽量保持客观，为了做出选择，我决定对一些目前由经过认证和经验丰富的专业人士开发的最受欢迎的 github 存储库进行一项小型研究。

那么，大玩家如何测试自己的项目呢？更重要的是，单元测试框架是如何自己进行单元测试的？

让我们看几个例子：

休眠

https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/test/java/org/hibernate/engine/spi/EntityEntryTest.java https://github.com/hibernate/hibernate -orm/blob/master/hibernate-core/src/test/java/org/hibernate/engine/spi/NonSortedExecutableListTest.java https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/ src/test/java/org/hibernate/engine/spi/SortedExecutableListTest.java https://github.com/hibernate/hibernate-orm/blob/master/hibernate-envers/src/test/java/org/hibernate/envers /test/JpaStaticMetamodelTest.java https://github.com/hibernate/hibernate-orm/blob/master/hibernate-hikaricp/src/test/java/org/hibernate/test/hikaricp/HikariCPConnectionProviderTest.java https://github.com/hibernate/hibernate-orm/blob/master/hibernate-proxool/src/test/java/org/hibernate/test/proxool/ProxoolConnectionProviderTest.java

春天

https://github.com/spring-projects/spring-framework/blob/master/spring-core/src/test/java/org/springframework/util/AntPathMatcherTests.java https://github.com/spring-projects /spring-framework/blob/master/spring-core/src/test/java/org/springframework/util/ClassUtilsTests.java https://github.com/spring-projects/spring-framework/blob/master/spring-核心/src/test/java/org/springframework/util/ObjectUtilsTests.java https://github.com/spring-projects/spring-framework/blob/master/spring-core/src/test/java/org/springframework /util/AutoPopulatingListTests.java

六月 4

https://github.com/junit-team/junit4/blob/master/src/test/java/junit/tests/extensions/ActiveTestTest.java https://github.com/junit-team/junit4/blob/master /src/test/java/junit/tests/extensions/RepeatedTestTest.java https://github.com/junit-team/junit4/blob/master/src/test/java/junit/tests/runner/ResultTest.java https ://github.com/junit-team/junit4/blob/master/src/test/java/org/junit/rules/TimeoutRuleTest.java

六月 5

https://github.com/junit-team/junit5/blob/master/platform-tests/src/test/java/org/junit/platform/launcher/core/DefaultLauncherTests.java https://github.com/junit -team/junit5/blob/master/platform-tests/src/test/java/org/junit/platform/launcher/core/LauncherDiscoveryRequestBuilderTests.java https://github.com/junit-team/junit5/blob/master/平台测试/src/test/java/org/junit/platform/launcher/listener/SummaryGenerationTests.java https://github.com/junit-team/junit5/blob/master/junit-jupiter-engine/src/test /java/org/junit/jupiter/engine/StandardTestClassTests.java https://github.com/junit-team/junit5/blob/master/junit-jupiter-engine/src/test/java/org/junit/jupiter/引擎/DiscoveryFilterApplierTests.java

谷歌真相

https://github.com/google/truth/blob/master/core/src/test/java/com/google/common/truth/DoubleSubjectTest.java https://github.com/google/truth/blob/master /core/src/test/java/com/google/common/truth/BigDecimalSubjectTest.java https://github.com/google/truth/blob/master/core/src/test/java/com/google/common/真相/DoubleSubjectTest.java

正如我们在上面的例子中所看到的，专业的开发人员似乎不太关心单一的断言诫命。事实上，他们大部分时间都违反了这条规则，看起来他们完全可以接受。也许他们忽略了它，因为这不是一个严格的规则，而只是一个建议。值得一提的是，即使是单元测试框架，大多数时候每次测试都会使用多个断言来测试自己。

所以我的结论很清楚：关于这个问题，在一个测试中拥有尽可能多的断言是完全有效的。如果专业开发人员正在这样做，您也可以这样做。

于 2017-04-08T10:09:24.130 回答