单元测试是否应该像UAT测试一样测试不同的不幸案例？

Question

在UAT测试中，我经常有以下几种或全部类型的测试:烟雾(页面到达端点加载)、愉快、悲伤、可选和审计。

这些测试类型中有多少类型适用于单元测试，哪些测试类型值得添加？例如，如果我确保方法的调用方不传递null，并且总是通过数组，那么对所传递的内容进行单元悲伤的空、无效等测试是否合理。我们现在是否应该这样做，因为这在将来是可能的，届时我们可能还没有意识到要增加它们吗？

目前，我认为我刚刚有一个单元测试的快乐和悲伤的测试。不过，这也是基于做一件事的小函数。想知道其他人对单元测试类型有什么建议吗？

Answer 1

理想情况下，单元测试应该测试每个代码路径，因为它们通常是最简单的，也是目前最快的测试方式。您应该能够为您拥有的每一个UAT至少运行数千个单元测试。因此，如果您的代码是完全可测试的，那么很可能添加一个单元测试来处理可悲的情况是一种胜利。

Answer 2

不是的。这两者的性质是完全不同的，并有不同的意图在一起。

单元测试只测试在开发代码中编写的面向公共的API。他们注定是孤立的，他们给出了关于发展状况的快速反馈。有时，它们也可以用于文档目的。这些工作大多是由开发人员完成的。

UAT对整个应用程序进行测试，主要涵盖端到端场景和不同的产品工作流。UAT测试在尝试模仿最终用户时往往要慢一些。这些都是由产品所有者和最终用户完成的。

有许多需要补充，但上述夫妇是主要的。