unit-testing - 你在什么时候达到单元测试矫枉过正？

Question

我目前正在做一个项目，我正在使用 NUnit 进行单元测试，使用 Moq 进行模拟，使用 MSpec 编写规范并使用 WebAii 测试 UI。

虽然我很享受整个体验并学习了很多关于测试什么和如何测试的知识，但我想知道这四个工具是否都有些过火了。

是否存在单元测试变得有点荒谬的点？是否有可能过度？什么是需要编写的合理测试？在您看来，什么只是不必要的细节？

编辑:
需要明确的是，与其说是我编写的测试数量，不如说是我使用的工具的广度。四个看起来很多，但如果其他人使用这种阵容效果很好，我想听听。

Answer 1

一次使用多个测试框架可以吗？

一些开源软件项目确实使用了几个测试框架。如果项目的开发人员不想推出自己的模拟，那么常见的设置是使用单元测试框架和模拟框架。

那么你什么时候达到单元测试的矫枉过正呢？

你很快就达到了单元测试的“矫枉过正”，而且你可能已经达到了。一般而言，有几种方法会导致过度测试，这会违背 TDD 的目的。 , BDD , ADD以及您使用的任何驱动方法。这是其中之一:

当您开始编写其他类型的测试时，就会达到单元测试过度使用的程度，就好像它们是单元测试一样。这应该通过使用模拟框架(测试仅与一个类隔离的交互)和规范框架(测试功能和指定要求)来解决。许多开发人员都混淆了，他们似乎认为以相同的方式对待所有不同类型的测试是个好主意，这导致了一些肮脏的混合。

即使 TDD 专注于单元测试，您仍然会发现自己在编写功能、集成和性能测试。但是你必须提醒自己，他们的范围大不相同 从单元测试。 这就是为什么有这么多测试工具可用，因为有不同类型的测试。 使用许多测试框架并没有错，而且它们中的大多数是相互兼容的。

所以在编写单元测试时有一个 couple of sweet spots编写测试时要考虑:

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 意义上的单元测试的目的。在大型项目中，这将非常耗时。

这个故事的寓意是，不要将单元测试与集成测试混淆。因为简单地说:它们是不同的。这并不是说其他​​类型的测试不好，而是应该将它们更多地视为规范或健全性检查。仅仅因为测试中断，它们可能并不表明代码是错误的。例如:

如果集成测试中断，则您的某些需求可能存在问题，需要修改需求、删除、替换或修改测试。

如果性能测试失败，根据它的实现方式，该测试的随机性质可能会让您认为它只是在该实例上运行缓慢。

唯一要记住的是，以易于区分和查找的方式组织测试。

你需要一直写测试吗？

有时省略测试用例通常是可以的，因为通过手动验证 smoke testing只是更容易做，不需要很多时间。从这个意义上说，手动冒烟测试是您启动应用程序以测试自己或其他尚未编写代码的人的功能的操作。也就是说，如果您要编写的自动化测试符合以下所有条件:

太复杂了

会占用你大量的工作时间来写

没有现成且易于使用的测试框架来处理它

不会给出太多返回，例如几乎没有回归的机会

与编写自动化测试相比，手动完成的工作量要少得多

...然后编写它并作为手动测试用例对其进行测试。如果手动冒烟测试只需要一分钟，那么编写测试用例需要几天时间，这是不值得的。