我同意与大多数人相反的观点: 不编写单元测试是可以的 特别是重原型的编程(例如AI)很难与单元测试相结合。

Unit Testing is one of the most adopted methodologies for high quality code. Its contribution to a more stable, independent and documented code is well proven . Unit test code is considered and handled as an a integral part of your repository, and as such requires development and maintenance. However, developers often encounter a situation where the resources invested in unit tests where not as fruitful as one would expect. In an ideal world every method we code will have a series of tests covering it’s code and validating it’s correctness. However, usually due to time limitations we either skip some tests or write poor quality ones. In such reality, while keeping in mind the amount of resources invested in unit testing development and maintenance, one must ask himself, given the available time, which code deserve testing the most? And from the existing tests, which tests are actually worth keeping and maintaining? See here

当您手动测试软件时，通常会使用一小组测试/操作。最终，您将自动修改输入数据或操作，以便围绕已知问题进行导航。应该有单元测试来提醒您某些事情不能正常工作。

我建议在编写代码之前编写测试，添加新的测试/数据来改进主代码的功能!

我是一名维护工程师，负责一个文档记录不佳、糟糕而庞大的代码库。我希望编写代码的人已经为它编写了单元测试。 每次我进行更改和更新产品代码时，我都担心自己可能会因为没有考虑某些条件而引入错误。 如果他们编写测试，那么对代码库的更改就会更容易、更快。(与此同时，代码库将处于更好的状态)..

我认为，在编写api或框架时，单元测试非常有用，因为这些api或框架必须持续多年，并由原始编码器以外的人使用/修改/发展。

当你说“我们的代码库不适合简单的测试”时，这是代码气味的第一个迹象。编写单元测试意味着您通常以不同的方式编写代码，以使代码更具可测试性。在我看来，这是一件好事，因为多年来我在编写代码时看到我必须为其编写测试，这迫使我提出更好的设计。

单元测试非常值得最初的投资。自从几年前开始使用单元测试以来，我发现了一些真正的好处:

回归测试消除了恐惧 对代码进行更改(什么都没有 就像看到代码的温暖光芒 每次有变化，要么工作，要么爆发 了) 以下的可执行代码示例 其他团队成员(包括你自己) 6个月的时间…) 无情的重构——这是令人难以置信的回报，试试吧!

代码片段可以极大地帮助减少创建测试的开销。创建能够在几秒钟内创建类大纲和相关单元测试fixture的代码片段并不困难。