[我有一个观点，我不能在上面看到]

“每个人都在进行单元测试，他们不一定意识到这一点——事实”

想想看，你写了一个函数来解析一个字符串并删除新的行字符。作为一个开发新手，你要么在命令行中通过Main()实现它来运行几个用例，要么用一个按钮组合一个可视化前端，将你的函数绑定到几个文本框和一个按钮上，然后看看会发生什么。

这就是单元测试——基本的和糟糕的组合在一起，但是你测试了一些情况下的代码段。

你写一些更复杂的东西。当您抛出一些用例(单元测试)并将其调试到代码中并进行跟踪时，它会抛出错误。你在浏览过程中查看这些值，并决定它们是对还是错。在某种程度上，这是单元测试。

这里的单元测试实际上是采用这种行为，将其形式化为结构化模式并保存，以便您可以轻松地重新运行这些测试。如果您编写了一个“适当的”单元测试用例而不是手动测试，那么它所花费的时间是相同的，或者随着您的经验的增加可能会更少，并且您可以一次又一次地重复它

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

使用单元测试套件，可以在保持其余功能不变的情况下对代码进行更改。这是一个很大的优势。当你完成新功能的编码时，你会使用单元测试套件和回归测试套件吗?

Yes - Unit Testing is definitely worth the effort but you should know it's not a silver bullet. Unit Testing is work and you will have to work to keep the test updated and relevant as code changes but the value offered is worth the effort you have to put in. The ability to refactor with impunity is a huge benefit as you can always validate functionality by running your tests after any change code. The trick is to not get too hung up on exactly the unit-of-work you're testing or how you are scaffolding test requirements and when a unit-test is really a functional test, etc. People will argue about this stuff for hours on end and the reality is that any testing you do as your write code is better than not doing it. The other axiom is about quality and not quantity - I have seen code-bases with 1000's of test that are essentially meaningless as the rest don't really test anything useful or anything domain specific like business rules, etc of the particular domain. I've also seen codebases with 30% code coverage but the tests were relevant, meaningful and really awesome as they tested the core functionality of the code it was written for and expressed how the code should be used.

在探索新的框架或代码库时，我最喜欢的一个技巧是为“它”编写单元测试，以发现事物是如何工作的。这是一个学习新事物的好方法，而不是阅读枯燥的文档:)

根据我的经验，在复杂的软件环境中，单元测试和集成测试是“必须的”。

为了说服团队中的开发人员编写单元测试，您可能需要考虑在开发环境中集成单元测试回归分析(例如，在您的日常构建过程中)。

一旦开发人员知道如果单元测试失败，他们就不必花那么多时间调试它来发现问题，他们就会更有动力去编写这些测试。

这里有一个工具可以提供这样的功能:

单元测试回归分析工具

单元测试的全部意义在于使测试变得简单。这是自动的。“make test”就完成了。如果您面临的问题之一是难以测试代码，那么这就是使用单元测试的最佳理由。