单元测试复杂交互的正确方法 [英] Correct Approach for Unit Testing Complex Interactions

问题描述

当我的方法从一开始就不正确时，我必须开始使用QualityTools.UnitTestFramework为我们开发的Web服务层编写一些单元测试.

I had to start writing some unit tests, using QualityTools.UnitTestFramework, for a web service layer we have developed, when my approach seemed to be incorrect from the beginning.

似乎单元测试应该能够以任何顺序运行，而不依赖于其他测试.

It seems that unit tests should be able to run in any order and not rely on other tests.

我最初的想法是要具有与以下测试(简化的示例)相似的功能，这些测试将以相同的顺序作为有序测试运行.

My initial thought was to have the something similar to the following tests (a simplified expample) which would run as an ordered test in the same order.

AddObject1SuccessTest
AddObject2WithSameUniqueCodeTest
(依赖于首先创建object1的第一个测试，然后期望失败)
AddObject2SuccessTest
UpdateObject2WithSameUniqueCodeTest
(依赖于首先创建了object1的测试，而第三次测试首先创建了object2，然后期望失败)
UpdateObject2SuccessTest
GetObjectListTest
DeleteObjectsTest
(使用添加的ID)

AddObject1SuccessTest
AddObject2WithSameUniqueCodeTest
(relies on first test having created object1 first then expects fail)
AddObject2SuccessTest
UpdateObject2WithSameUniqueCodeTest
(relies on first test having created object1 and thrid test having created object2 first then expects fail)
UpdateObject2SuccessTest
GetObjectListTest
DeleteObjectsTest
(using added IDs)

但是，例如，测试之间没有状态，也没有明显的方式将已添加的ID传递给deletetest.

However, there is no state between tests and no apparent way of passing say added IDs to the deletetest for example.

那么，是否存在根据场景进行单元交互测试的正确方法呢?

So, is it then the case that the correct approach for unit testing complex interactions is by scenario?

例如

AddObjectSuccessTest
(创建一个对象，获取它以验证数据，然后将其删除)
AddObjectWithSameUniqueCodeTest
(创建对象1，然后尝试创建失败的对象2，然后删除对象1)
UpdateObjectWithSameUniqueCodeTest
(创建对象1，然后创建对象2，然后尝试将对象2更新为具有与对象1相同的唯一代码，但失败，然后删除对象1和对象2)

AddObjectSuccessTest
(which creates an object, gets it to validate the data and then deletes it)
AddObjectWithSameUniqueCodeTest
(which creates object 1 then attempts to create object 2 with a fail and then deletes object 1)
UpdateObjectWithSameUniqueCodeTest
(which creates object 1 then creates object 2 and then attempts to update object 2 to have the same unique code as object 1 with a fail and then deletes object 1 and object 2)

我是不是来错了?

谢谢

推荐答案

单元测试的宗旨是每个测试用例应独立于任何其他测试用例. MSTest(以及所有其他单元测试框架)通过不保证测试的运行顺序来强制执行此操作-有些(xUnit.NET)甚至可以随机化每次测试运行之间的顺序.

It is a tenet of unit testing that each test case should be independent of any other test case. MSTest (as well as all other unit testing frameworks) enforce this by not guaranteeing the order in which tests are run - some (xUnit.NET) even go so far as to randomize the order between each test run.

将单元压缩成简单的交互也是推荐的最佳实践.尽管无法提供严格的规则，但如果交互过于复杂，则不是单元测试.无论如何，复杂的测试都很脆弱，并且维护费用很高，这就是为什么首选简单的测试的原因.

It is also a recommended best practice that units are condensed into simple interactions. Although no hard and fast rule can be provided, it's not a unit test if the interaction is too complex. In any case, complex tests are brittle and have a very high maintainance overhead, which is why simple tests are preferred.

听起来您的测试之间存在共享状态.这导致相互依赖的测试，应避免使用.相反，您可以编写可重用的代码来设置每个测试的前提条件状态，以确保该状态始终正确.

It sounds like you have a case of shared state between your tests. This leads to interdependent tests and should be avoided. Instead you can write reusable code that sets up the pre-condition state for each test, ensuring that this state is always correct.

这种先决条件状态称为灯具.这本书 xUnit测试模式包含许多信息和指导有关如何在许多不同场景中管理灯具的信息.

Such a pre-condition state is called a Fixture. The book xUnit Test Patterns contains lots of information and guidance on how to manage Fixtures in many different scenarios.

这篇关于单元测试复杂交互的正确方法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！