如何处理长时间运行的单元测试？
我有大约 100 个单元测试，覆盖率为 %20，我正在尝试增加覆盖率，而且这是一个正在开发的项目，因此请不断添加新的测试。
目前在每次构建后运行我的测试是不可行的，它们大约需要 2 分钟。
测试包括：
- 从测试文件夹中读取的文件（数据驱动的样式来模拟一些 HTTP 内容）
- 对本地 Web 服务器执行实际的 HTTP 请求（模拟起来很痛苦，所以我不会）
- 并非所有这些都适用-测试，但也有相当复杂的多线程类需要测试，我确实测试了测试的整体行为。 这可以被视为功能测试，但也需要每次运行。
大多数功能需要读取 HTTP、执行 TCP 等。我无法更改它们，因为这就是项目的整个想法，如果我更改这些测试，测试内容将毫无意义。
另外，我认为我没有运行单元测试最快的工具。 我当前的设置使用 VS TS，以 Gallio 和 nUnit 作为框架。 我认为VS TS + Gallio也比其他人慢一点。
您会建议我做什么来解决这个问题？ 我想在每一点点改变 btu 之后运行单元测试，目前这个问题正在中断我的流程。
进一步澄清编辑：
代码高度耦合！不幸的是，更改就像一个巨大的重构过程。 这里面有一个鸡生蛋综合症，我需要单元测试来重构这么大的代码，但如果我不重构它，我就不能有更多的单元测试:)
高度耦合的代码不允许我将测试分成更小的块。 另外，我不测试私人的东西，这是个人选择，这让我发展得更快，并且仍然获得大量的好处。
我可以确认所有单元测试（具有适当的隔离）实际上都非常快，并且我对它们没有性能问题。
进一步说明：
代码高度耦合！不幸的是，更改就像一个巨大的重构过程。 这里面有一个鸡生蛋综合症，我需要单元测试来重构这么大的代码，但如果我不重构它，我就不能有更多的单元测试:)
高度耦合的代码不允许我将测试分成更小的块。 另外，我不测试私人的东西，这是个人选择，这让我发展得更快，并且仍然获得大量的好处。
我可以确认所有单元测试（具有适当的隔离）实际上都非常快，并且我对它们没有性能问题。
I've got about 100 unit tests and with a coverage of %20, which I'm trying to increase the coverage and also this is a project in development so keep adding new tests.
Currently running my tests after every build is not feasible they takes about 2 moments.
Test Includes:
- File read from the test folders (data-driven style to simulate some HTTP stuff)
- Doing actual HTTP requests to a local web-server (this is a huge pain to mock, so I won't)
- Not all of them unit-tests but there are also quite complicated Multithreaded classes which need to be tested and I do test the overall behaviour of the test. Which can be considered as Functional Testing but need to be run every time as well.
Most of the functionality requires reading HTTP, doing TCP etc. I can't change them because that's the whole idea of project if I change these tests it will be pointless to test stuff.
Also I don't think I have the fastest tools to run unit tests. My current setup uses VS TS with Gallio and nUnit as framework. I think VS TS + Gallio is a bit slower than others as well.
What would you recommend me to fix this problem? I want to run unit-tests after every little bit changes btu currently this problem is interrupting my flow.
Further Clarification Edit:
Code is highly coupled! Unfortunately and changing is like a huge refatoring process. And there is a chicken egg syndrome in it where I need unit tests to refactor such a big code but I can't have more unit tests if I don't refactor it :)
Highly coupled code doesn't allow me to split tests into smaller chunks. Also I don't test private stuff, it's personal choice, which allow me to develop so much faster and still gain a large amount of benefit.
And I can confirm that all unit tests (with proper isolation) quite fast actually, and I don't have a performance problem with them.
Further Clarification:
Code is highly coupled! Unfortunately and changing is like a huge refatoring process. And there is a chicken egg syndrome in it where I need unit tests to refactor such a big code but I can't have more unit tests if I don't refactor it :)
Highly coupled code doesn't allow me to split tests into smaller chunks. Also I don't test private stuff, it's personal choice, which allow me to develop so much faster and still gain a large amount of benefit.
And I can confirm that all unit tests (with proper isolation) quite fast actually, and I don't have a performance problem with them.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
对我来说，这些听起来不像单元测试，而更像功能测试。 没关系，自动化功能测试很好，但功能测试速度很慢是很常见的。 他们正在测试整个系统（或其中的大部分）。
单元测试往往很快，因为它们测试的是与其他所有事物隔离的一件事。 如果您无法独立于其他事物进行测试，那么您应该考虑到您编写的代码的警告信号过于紧密耦合。
您能说出哪些测试是单元测试（仅测试 1 件事）还是功能测试（同时测试 2 件事或更多件事）？ 哪些快，哪些慢？
These don't sound like unit tests to me, but more like functional tests. That's fine, automating functional testing is good, but it's pretty common for functional tests to be slow. They're testing the whole system (or large pieces of it).
Unit tests tend to be fast because they're testing one thing in isolation from everything else. If you can't test things in isolation from everything else, you should consider that a warning sign that you code is too tightly coupled.
Can you tell which tests you have which are unit tests (testing 1 thing only) vs. functional tests (testing 2 or more things at the same time)? Which ones are fast and which ones are slow?
您可以将测试分为两组，一组用于短期测试，一组用于长时间运行的测试，并降低运行长时间测试的频率，同时在每次更改后运行短期测试。 除此之外，模拟来自网络服务器的响应和应用程序发出的其他请求将导致测试运行时间缩短。
You could split your tests into two groups, one for short tests and one for long-running tests, and run the long-running tests less frequently while running the short tests after every change. Other than that, mocking the responses from the webserver and other requests your application makes would lead to a shorter test-run.
我建议您采用组合方法来解决您的问题：
我从上面提到的书中学到的最重要的事情之一：没有什么魔法，使用遗留代码是痛苦，并且永远将会痛苦。 你能做的就是接受这个事实，并尽力慢慢摆脱困境。
I would recommend a combined approach to your problem:
One of the most important things I learned from the book mentioned above: there is no magic, working with legacy code is pain, and always will be pain. All you can do is accept that fact, and do your best to slowly work your way out of the mess.
首先，这些不是单元测试。
在每次小的更改之后运行这样的功能测试并没有多大意义。 经过相当大的更改后，您将需要运行功能测试。
其次，不要害怕模拟应用程序的 Http 部分。 如果您确实想对应用程序进行单元测试，那么它是必须的。 如果您不愿意这样做，您将浪费更多时间尝试测试实际逻辑、等待 HTTP 请求返回并尝试设置数据。
我会保留您的集成级别测试，但努力创建真正的单元测试。 这将解决您的速度问题。 真正的单元测试没有数据库交互，也没有HTTP交互。
First, those are not unit tests.
There isn't much of a point running functional tests like that after every small change. After a sizable change you will want to run your functional tests.
Second,don't be afraid to mock the Http part of the application. If you really want to unit test the application its a MUST. If your not willing to do that, you are going to waste a lot more time trying to test your actual logic, waiting for HTTP requests to come back and trying to set up the data.
I would keep your integration level tests, but strive to create real unit tests. This will solve your speed problems. Real unit tests do not have DB interaction, or HTTP interaction.
我总是使用“LongTest”类别。 这些测试每晚执行，而不是白天执行。 这样您就可以大大减少等待时间。 尝试一下：对您的单元测试进行分类。
I always use a category for "LongTest". Those test are executed every night and not during the day. This way you can cut your waiting time by a lot. Try it : category your unit testing.
听起来您可能还需要管理开发团队的期望。
我假设人们每天都会进行多次构建，并且预计在每次构建后运行测试。 您可能会很乐意将您的测试计划更改为在午餐期间运行测试构建，然后在晚上运行另一个测试。
我同意布拉德的观点，这些听起来像是功能测试。 如果您可以将代码分开，那就太好了，但在那之前我会切换到不太频繁的测试。
It sounds like you may need to manage expectations amongst the development team as well.
I assume that people are doing several builds per day and are epxected to run tests after each build. You might we be well served to switch your testing schedule to run a build with tests during lunch and then another over night.
I agree with Brad that these sound like functional tests. If you can pull the code apart that would be great, but until then i'd switch to less frequent testing.