我应该在同一个项目中混合使用单元测试和集成测试吗?

发布于 2024-07-10 14:38:02 字数 282 浏览 7 评论 0原文

我正在使用 NUnit 来测试我的 C# 代码,到目前为止,我一直将单元测试(快速运行的测试)和集成测试(运行时间较长的测试)分开,并放在单独的项目文件中。 我使用 NUnit 进行单元测试和集成测试。 我刚刚注意到 NUnit 提供的 category 属性,因此测试可以分类。 这就引出了一个问题,我是否应该将它们混合在一起并简单地使用类别属性来区分它们?

I am using NUnit to test my C# code and have so far been keeping unit tests (fast running ones) and integration tests (longer running) separate, and in separate project files. I use NUnit for doing both the unit tests and the integration tests. I just noticed the category attribute that NUnit provides, so that tests can be categorized. This begs the question, should I mix them together and simply use the category attribute to distinguish between them?

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

扫码二维码加入Web技术交流群

发布评论

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

评论(6

[浮城] 2024-07-17 14:38:02

如果将它们分开并不是太困难,那么现在

应该尽早并经常运行单元测试(例如,每次更改某些内容时,在签入之前、签入之后),并且应该在很短的时间内完成。

集成测试应定期运行(例如每天),但可能需要大量时间和资源才能完成,

因此最好将它们分开

if it is not too difficult to separate them, do so now

unit tests should be run early and often (e.g. every time you change something, before check-in, after check-in), and should complete in a short time-span.

integration tests should be run periodically (daily, for example) but may take significant time and resources to complete

therefore it is best to keep them separate

请持续率性 2024-07-17 14:38:02

如果可能的话将它们分开,因为集成测试通常比单元测试花费更长的时间。
也许您的项目不断增长,最终需要进行大量测试,所有这些测试都需要很短的时间(集成测试除外),并且您希望尽可能频繁地运行单元测试...

seperate them if possible, because integration tests normally take much longer than UnitTests.
Maybe your project grows and you end up with very much tests, all which take a short amount of time - except the integration tests - and you want to run your UnitTests as often as possible...

青柠芒果 2024-07-17 14:38:02

我发现使用单独的项目进行单元测试和集成测试往往会在项目中创建太多的顶级工件。 即使我们是 TDD 等等,我仍然认为正在开发的代码应该至少值得我的项目结构顶层的一半。

I find that using separate projects for unit test and integration tests tends to create a little too many top level artifacts in the projects. Even though we're TDD and all, I still think the code being developed should be deserving at least half of the top-level of my project structure.

娇女薄笑 2024-07-17 14:38:02

我认为这并不是那么重要,但将它们分开听起来是一个更好的主意,因为隔离、自动化会更容易。 类别功能很好,但从可用性的角度来看并不是那么好。

I don't think it really matters that much but separating them sounds like a better idea, since isolation, automation will be so easier. And category feature is nice but not that good from usability point of view.

流年已逝 2024-07-17 14:38:02

[类别] 背后的最初动机是为了解决您提到的问题。 它还旨在创建更广泛的测试套件,但这正是您正在做的事情。

请小心[类别]。 并非所有测试运行程序都像 NUnit gui 那样支持它(或者确实如此,我有一段时间没有升级了)。 在过去,如果该属性位于类本身上,一些跑步者会忽略该属性,或者干脆将其全部忽略。 大多数现在似乎都可以工作。

The original motivation behind [Category] was to solve the problem you mention. It was also intended to create broader test suites but that is kind of what you are doing.

Do be careful with [Category]. Not all test runners support it the same way the NUnit gui does (or did, I haven't upgraded in a while). In the past some runners would ignore the attribute if it was on the class itself or just ignore it all together. Most seem to work now.

扛起拖把扫天下 2024-07-17 14:38:02

我会继续使用您当前使用的任何方法。 这更多的是一个意见问题,您不想重新调整整个测试方法。

I would keep with whatever method you're currently using. It's more of an opinion thing, and you wouldn't want to have to re-tool your whole testing method.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文