当前位置：文江博客话题详情

批量运行时单元测试失败

发布于 2024-09-13 15:54:27 字数 88 浏览 9 评论 0原文

我是单元测试的新手。我创建了各种测试，当我逐一运行测试时，所有测试都通过了。但是，当我作为批处理整体运行时，某些测试失败了。为什么会这样呢？我该如何纠正这个问题？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

〃安静 2024-09-20 15:54:27

为了解决这个问题，在编写单元测试时遵循某些规则很重要。有些规则很容易遵循和应用，而其他规则可能需要根据您的具体情况进一步考虑。

每个测试都应该设置一组唯一的数据。当您使用持久数据（例如数据库中的数据）时，这一点尤其重要。当测试创建具有特定用户 ID 的用户时，编写测试以便每次使用不同的用户 ID。例如 (C#)：

var user = new User(Guid.NewGuid());

在每个测试结束时，清理测试创建的数据。例如，在拆卸方法中删除您创建的数据（C#、NUnit）：

[TearDown]
public void TheTearDownMethod() {
    _repository.Delete(_user);
}

可能存在变化，例如，当您针对数据库进行测试时，您可以选择在运行测试套件之前加载备份。如果您精心设计测试，则无需在每次测试（或测试子集）后清理数据库。

为了从您现在所在的位置（每个测试在单独运行时通过）到达您希望按顺序运行前两个测试的位置，请让它们通过。然后按顺序运行三个，使它们通过，等等。在每次迭代中确定先前的测试导致添加的测试失败。解决这种依赖性。通过这种方式，您可以学到很多关于测试的知识，同时也了解如何避免编写相互依赖的测试。

一旦套件传递了一个补丁，就经常运行它，以便您尽早检测依赖性。

这并没有涵盖所有场景和变化，但希望能为您提供在现有基础上进行构建的指南。

To resolve this issue it is important to follow certain rules when writing unit tests. Some of the rules are easy to follow and apply while other may need further considerations depending your circumstances.

Each test should set up a unique set of data. This is in particular important when you work with persistent data, e.g. in a database. When the test creates a user with a particular user id, then write the test so that it uses a different user id each time. For example (C#):

var user = new User(Guid.NewGuid());

At the end of each test, cleanup the data that the test has created. For example in the tear down method remove the data that you created (C#, NUnit):

[TearDown]
public void TheTearDownMethod() {
    _repository.Delete(_user);
}

Variations are possible, e.g. when you test against a database you may choose to load a backup just before you run the test suite. If you craft your tests carefully you don't need to cleanup the database after each test (or subset of tests).

To get from where you are now (each test passes when run in isolation) to where you would like to be start with running the first two tests in sequence, make them pass. Then run three in sequence, make them pass, etc. In each iteration identify what previous test causes the added test to fail. Resolve that dependency. This way you learn a lot about your tests but also how to avoid writing tests that depend on each other.

Once the suite passes in one patch run it frequently so that you detect dependency as early as possible.

This doesn't cover all scenarios and variations but hopefully gives you a guideline for building on what you already have.

回复收藏 0 原文