使用不独立的单元测试来创建用例测试(场景测试)

本文关键字：测试 独立 单元测试 创建 | 更新日期: 2023-09-27 18:21:43

我正在实现一个小型API，它向服务器发送不同的请求并处理响应。我正在使用Moq和NUnit，并尝试以测试优先的方式实现所有内容。我试图将所有内容封装到接口中，这样我就可以模拟它们，这非常有效。在某个时候，我的API也由QA使用真实数据（来自服务器）进行测试，因为服务器也是并行开发的，所以有时无法判断哪里发生了错误。因此，我只写了一个带有一些单元测试的测试类，这些测试基本上只是向服务器发送请求，并检查是否有响应返回。类似的东西：

[Test]
    public void LoginShouldBeSuccesful()
    {
       result = webclient.UploadString(https://someURL.com, "POST", query);
       Assert.That(result,Is.Not.Null);
    }

这使得我可以很容易地在VS中测试服务器是否已经启动并运行，是否已经实现了一些请求并正在工作等等。（这比使用某些浏览器REST API插件要快）。然而，我添加了越来越多的依赖于不同web请求的测试（我已经将其放入单元测试中）。因此，例如，当我想测试一个删除用户生成的数据库条目的web请求时，我首先必须运行Login单元测试->将响应（令牌）添加到GenerateDBEntry单元测试->向DeleteEntry请求添加EntryID。

我知道这违背了单元测试的原则，因为它们应该彼此完全独立地运行测试，但我想知道是否有一种方法可以对它们进行排序并相互依赖（通过返回值），这样我就可以创建实际用例的测试类。如果可能的话，我希望每个测试类都有一个用例。

使用不独立的单元测试来创建用例测试(场景测试)

我认为区分并使用最适合工作的工具是很有用的。您所描述的是规范测试，这是行为驱动设计（BDD）的领域。

C#BDD测试套件的简短列表包括：

  • SpecFlow--网站目前似乎无法访问，但这个问题有更多信息
  • NSpec
  • 规格For

这些是围绕测试用例而设计的，并帮助您设计可测试的用例。关键的区别在于BDD工具是为确保应用程序作为一个整体按设计工作而设计的。TDD工具旨在确保每个部分都能按设计工作。语言、术语和概念可以更好地支持您尝试做的事情。

NUnit限制：

  • 您不能强制执行命令。你在一个工具中看到的任何订单都不能保证在另一个工具上也能正常工作（我在实践中看到了这一点）。一些单元测试运行程序按字母顺序排序，而另一些则保持类中定义的顺序
  • 测试不能相互依赖。原因和子弹头一样

NUnit和任何XUnit风格的单元测试框架（JUnit等）在这一点上都非常固执己见。驱动单元测试的设计约束是：

  • 单元测试必须是一致、隔离和原子（但不持久）。也就是说，任何一个单元测试都必须能够独立运行，每次都能产生相同的结果，并且不能依赖或影响任何其他单元测试

一些单元测试框架为了确保这些需求而煞费苦心，甚至动态加载DLL、运行测试、卸载它，并使用新的类加载器重复，以确保静态值不会影响其他测试。

恐怕您将不得不在设置和拆卸过程中做大量工作，以使单元测试按照您想要的方式运行。您甚至可能不得不人为地将测试划分为不同的类，以确保事件的正确顺序按照您期望的顺序发生。

这不是适合这份工作的工具。这就是我推荐BDD方法的原因，因为您可以使用这些工具强加顺序和依赖关系。

相关文章：