#1 楼
是的，这是单元测试的理想情况。要查看另一种情况-如果您编写的软件将来不会更改，那么也许可以考虑跳过测试。当然，我还没有使用过这样的软件：） TDD和BDD的支持者也会争辩说，即使在那种情况下，您仍然应该使用那些技术。他们将测试视为设计过程中必不可少的关键部分，而不是使用传统的“验证检查”方法进行测试。将来可以更改而不会破坏它。
因此，如果您真正实践TDD并在使它们通过的应用程序代码之前编写测试，以使测试驱动实现，那么跳过测试甚至不会发生。但是，如果编写的测试满足“最小覆盖率％级别”，并且在应用代码之后编写，那么它们的价值就会降低，质量会受到极大的损害。
您可能会认为您将有时间编写单元产品安定下来后进行测试。这是一个非常常见的谬论，通常在您要求产品经理几个星期编写测试但不实现功能时会遇到现实。这种陈述通常效果不佳，以我的经验，这种做法永远不会发生。
重复一遍是值得的-如果功能不断变化，那恰恰是单元测试是程序员最好的朋友的一种情况，要确保即使测试失败，它们也不会破坏东西变化很大。
将测试视为程序员最有价值的工具，而不应该避免。
我认为在所有情况下手动测试都非常有价值，但我确实认为“单元”测试是根据定义自动执行。这意味着您可以进行广泛的手动测试，而无需进行单元测试，即在2000年之前进行开发:)
关于永不更改的软件的最后一则说明-例如，搭载在航天飞机上的软件-想猜想它们是否可以进行测试？ （有关未经过适当测试的示例，请参阅“火星气候轨道器”。糟糕！）。因此，我们学会了对这种永不改变的软件进行大量的测试。
评论
我真的不同意可以在不更改软件的情况下跳过测试，特别是如果考虑使用TDD或BDD方法。
–bracco23
20年8月6日在14:47
@ bracco23谢谢。我同意您的意见，并相应地修改了帖子：）
–迈克尔·杜兰特（Michael Durrant）
20年8月6日在19:59
对我来说似乎很公平-如果软件永不更改，那么手动进行测试肯定比编写足够的单元测试要快。当然，作为开发人员，如果真的没有任何变化，那么您就不会考虑它，如果它只是“一旦改变”，我将非常怀疑。但是，如果它真的不会改变，那么是的，单元测试效率不高。如果没有更改，TDD / BDD中的最后一个D甚至意味着什么？
–马克
20年8月7日在13:35
#2 楼
是的，编写正确形式的单元测试的想法是使更改成本保持较低。如果您进行了很多更改，它们将在这里帮助您更快地完成任务。大多数人犯的最大错误是测试实现而不是行为，这会增加更改成本，因为您构建了更改检测器。这些测试应有助于您轻松重构体系结构以适应新的变化。
阅读：
https://medium.com/@kentbeck_7670/programmer-test-principles-d01c064d7934
https://refactoring.com/
http://www.agilemodeling.com/essays/costOfChange.htm
http://www.extremeprogramming.org/rules/testfirst.html
评论
单元测试将始终在某种程度上测试实现，因为它们绑定到具体的类和方法。因此，它们不如更高级别的测试。
–达沃
20年8月6日在17:04
@Davor单元不一定是一个类，单元测试可以很好地测试接口，因此不是特定于实现的，因此，并非总是如此。即使您使用方法，那仍然可以是一个相对抽象的测试，即您应该能够更改一个类的所有内部工作方式，并且仍然保持公共方法完整无缺。当然，您可能需要调整一些模拟。但是，您可能也是如此内心深处，以至于只要单元合同保持不变，单元测试就不会受到周围所有更改的影响。单元测试并不逊色，它们只是具有不同的属性。
–弗兰克·霍普金斯
20年8月7日，0：25
@FrankHopkins-不，您无法测试界面。您可以测试实现接口的类，并且接口本身也是实现。方法的存在也是如此。单元测试仅在类的公共接口永不更改（几乎从未更改）时才有用。
–达沃
20年8月7日，11：43
@Davor，您无需测试接口，但可以根据接口定义的API进行测试，并且与实现类的内部逻辑相比，更改的可能性较小。用您的论点来说，一切都是实现，因为每个级别上的一切都可能在某个时刻发生更改。不，单元测试不仅在内容不变时有用。当公共方法，尤其是接口方法发生变化（实现细节或接口规范）时，它们特别有用，因为它们随后反映了调整后的合同并为您提供了确定的合同。
–弗兰克·霍普金斯
20年8月7日，11：57
@Davor但可惜，由于这既不是改善答案也不是帮助进一步理解，所以我不在讨论之列。
–弗兰克·霍普金斯
20年8月7日，11：58
#3 楼
是。因为那些不变的位仍然需要测试。其余的确实会发生变化，好吧，这只是流程的一部分，您只需要偶尔更改一下内容即可。编写测试可以让您考虑整个问题，这是一个好的做法。如果没有测试，问题可能会一直存在到产品中，直到以后再解决，这可能会使修复成本高昂。代替自动测试，您可以选择手动测试。不是对立面，不是一个或另一个。这些都适合于不同的问题和风险。
#4 楼
确切地说，编写单元测试只是浪费时间：如果您已经在使用依赖类型的证明助手来数学上保证所有输入的正确性。大约占所有软件开发的0.01％，这显然不是您所需要的。在所有情况下，使用普通的编程语言时，单元测试是一个好主意，并且从统计上讲，它将节省更多的调试时间。书面。即使对于简单的一次性脚本也是如此，正如其他答案所说，对于将来会发生很大变化的项目，实际上更多。
评论
如果要扔掉很多代码，是否应该有人在第一阶段花费时间/成本来编写代码？大概是因为您不知道哪个位，所以才这样做。您将学习和迭代。但是您将要确信未删除的位仍然可以在该过程中正常工作，并且自动化测试（单元或其他方式）使您的反馈循环实质上更短，更可重复。