你在什么时候达到单元测试矫枉过正? [英] At what point do you reach Unit Testing overkill?
问题描述
我目前正在从事一个项目，我正在使用 NUnit 进行单元测试、使用 Moq 进行模拟、使用 MSpec 编写规范以及使用 WebAii 测试 UI.
I'm currently working on a project where I'm unit testing with NUnit, mocking with Moq, writing specifications with MSpec and playing around with testing the UI with WebAii.
虽然我很享受整个体验并学习了很多关于测试什么和如何测试的知识，但我想知道这四个工具是否都有些过火.
While I'm enjoying the experience on the whole and learning plenty about what and how to test, I can help wondering if all four of these tools is going a bit overboard.
有没有哪一点使单元测试变得有点荒谬?是否有可能过度?编写哪些合理的测试?在您看来，哪些只是不必要的细节?
Is there a point at which unit testing becomes a bit absurd? Is it possible to overdo it? What are reasonable tests to write and what - in your view - is just unnecessary detail?
需要明确的是，与其说是我编写的测试数量，不如说是我使用的工具的广度.四个看起来很多，但如果其他人使用这种阵容效果很好，我想听听.
To be clear, it's not so much the quantity of tests I'm writing so much as it's the breadth of tools I'm using. Four seems a lot, but if other people are using this sort of line-up to good effect, I want to hear about it.
推荐答案
一次使用多个测试框架可以吗?
一些开源软件项目确实使用了多个测试框架.如果项目的开发人员不想推出自己的模拟，常见的设置是使用单元测试框架和模拟框架.
Is it okay to use many testing frameworks at once?
Some open-source software projects do use several testing frameworks. A common setup would be the use unit-testing framework with mocking framework if the developers of the project don't want to roll their own mocks.
您很快就达到了单元测试矫枉过正"，而且您可能已经达到了.一般而言，有几种过度测试的方法会违背TDD、BDD、ADD 以及您使用的任何驱动方法.这是其中之一:
You reach unit testing "overkill" quickly and you might have reached it already. There are several ways to overdo testing in general that defeats the purpose of TDD, BDD, ADD and whatever driven approach you use. Here is one of them:
当您开始编写其他类型的测试时，就会达到单元测试的矫枉过正，就好像它们是单元测试一样.这应该通过使用模拟框架(测试仅与一个类隔离的交互)和规范框架(测试功能和指定要求)来解决.许多开发人员都混淆了，他们似乎认为以相同的方式对待所有不同类型的测试是个好主意，这导致了一些肮脏的混合.
Unit testing overkill is reached when you start writing other types of tests as if they were unit tests. This is supposed to be fixed by using mocking frameworks (to test interactions isolated to one class only) and specification frameworks (to test features and specified requirements). There is a confusion among a lot of developers who seem to think it is a good idea to treat all the different types of tests the same way, which leads to some dirty hybrids.
即使 TDD 专注于单元测试，您仍然会发现自己在编写功能、集成和性能测试.但是，您必须提醒自己，它们的范围与单元测试有很大不同.这就是为什么有这么多测试工具可用，因为有不同类型的测试.使用许多测试框架并没有错，而且大多数测试框架彼此兼容.
Even though TDD focuses on unit testing you will still find yourself writing functional, integration and performance tests. However you have to remind yourself that their scope are vastly different from unit tests. This is why there are so many testing tools available as there are different types of tests. There is nothing wrong with using many testing frameworks and most of them are compatible with each other.
所以在编写单元测试时有一个 编写测试时要考虑的几个甜蜜点:
So when writing unit tests there are a couple of sweet spots to think about when writing tests:
unit test dirty hybrids integration test
--------- ------------- ----------------
* isolated * using many classes
* well defined | * tests a larger feature
* repeatable | * tests a data set
|
| | |
| | |
v v v
O <-----------------------------------------------------> O
^ ^ ^
| | |
sweet spot world full of pain sweet spot
单元测试很容易编写，而且您想编写很多单元测试.但是，如果您编写的测试具有太多依赖项，一旦需求开始发生变化，您最终将需要做大量工作.当代码在具有太多依赖项的单元测试中中断时，您必须检查许多类的代码，而不是一个且只有一个类.这意味着您必须检查它的所有依赖项，以查看问题出在哪里，这违背了 TDD 意义上的单元测试的目的.在大型项目中，这将非常耗时.
Unit tests are easy to write and you want to write a lot of them. But if you write a test that has too many dependencies you'll end up with a lot of work once requirements start to change. When code breaks in a unit test that has too many dependencies you have to check through the code of many classes rather than one and only one class. This means you have to check all of its dependencies to see where the problem is which defeats the purpose of unit-testing in TDD sense. In a large project this would be incredibly time consuming.
这个故事的寓意是，不要将单元测试与集成测试混为一谈.因为简单地说:它们是不同的.这并不是说其他类型的测试不好，而是应该将它们更多地视为规范或健全性检查.仅仅因为测试中断，它们可能并不表明代码是错误的.例如:
The moral of this story is, do not mix up unit tests with integration tests. Because simply put: they are different. This is not to say that the other types tests are bad, but they should be treated more as a specifications or sanity checks instead. Just because the test breaks they may not be an indication of the code being wrong. For example:
- 如果集成测试中断，则您的某些需求可能存在问题，需要修改需求、删除、替换或修改测试.
- 如果性能测试中断，根据它的实施方式，该测试的随机性质可能会让您认为它只是在该实例上运行缓慢.
- If an integration test breaks, there may be a problem with some requirement that you have and need to revise the requirement, remove, replace or modify the test.
- If a performance test breaks, depending on how it was implemented the stochastic nature of that test may lead you to think it was just running slow on that instance.
唯一要记住的是，以易于区分和查找的方式组织测试.
The only thing to keep in mind is to organize the tests in a way that they are easy to distinguish and find.
有时可以省略测试用例，通常是因为通过手动验证冒烟测试只是更容易做，不需要很多时间.从这个意义上说，手动冒烟测试是您启动应用程序以测试自己或其他尚未编写代码的人的功能的操作.也就是说，如果您要编写的自动化测试所有以下内容:
There are times when it is okay to omit test cases usually because verification through manual smoke testing is just easier to do and doesn't take a lot of time. Manual smoke test in this sense is the action of you starting up your application to test the functionality yourself or someone else who hasn't coded your stuff. That is if the automated test you're going to write is all of the following:
- 太复杂和令人费解了
- 写作会占用您大量的工作时间
- 没有现成且易于使用的测试框架来处理它
- 不会带来太多回报，例如几乎没有回归的机会
- 与编写自动化测试相比，手动完成的工作量要少得多
...然后编写它并作为手动测试用例对其进行测试.如果手动冒烟测试只需要一分钟，那么编写测试用例需要几天时间是不值得的.
…then write it and test it as a manual test case. It's not worth it if the test case will take several days to write when smoke testing it manually only takes a minute.
这篇关于你在什么时候达到单元测试矫枉过正?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
