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

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

我最近在我的工作场所经历了完全相同的经历，发现大多数人都知道理论上的好处，但必须具体地向他们推销这些好处，所以下面是我使用的(成功地)要点:

它们在执行负测试(处理意外输入(空指针、越界值等)时节省了时间，因为您可以在单个进程中完成所有这些。 它们在编译时提供关于更改标准的即时反馈。 它们对于测试在正常运行时可能不会公开的内部数据表示非常有用。

还有那个大的…

您可能不需要单元测试，但是当其他人进入并在没有完全理解的情况下修改代码时，它可以捕捉到他们可能犯的许多愚蠢的错误。

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

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

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

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

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

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

thetalkingwalnut问道: 有什么好方法可以让团队中持怀疑态度的开发人员相信单元测试的价值?

Everyone here is going to pile on lots of reasons out of the blue why unit testing is good. However, I find that often the best way to convince someone of something is to listen to their argument and address it point by point. If you listen and help them verbalize their concerns, you can address each one and perhaps convert them to your point of view (or at the very least, leave them without a leg to stand on). Who knows? Perhaps they will convince you why unit tests aren't appropriate for your situation. Not likely, but possible. Perhaps if you post their arguments against unit tests, we can help identify the counterarguments.

It's important to listen to and understand both sides of the argument. If you try to adopt unit tests too zealously without regard to people's concerns, you'll end up with a religious war (and probably really worthless unit tests). If you adopt it slowly and start by applying it where you will see the most benefit for the least cost, you might be able to demonstrate the value of unit tests and have a better chance of convincing people. I realize this isn't as easy as it sounds - it usually requires some time and careful metrics to craft a convincing argument.

单元测试是一种工具，就像任何其他工具一样，应该以这样一种方式进行应用，即收益(捕捉错误)大于成本(编写它们的工作)。如果它们没有意义，就不要使用它们，记住它们只是你工具库的一部分(例如检查、断言、代码分析器、形式化方法等)。我告诉开发者的是:

They can skip writing a test for a method if they have a good argument why it isn't necessary (e.g. too simple to be worth it or too difficult to be worth it) and how the method will be otherwise verified (e.g. inspection, assertions, formal methods, interactive/integration tests). They need to consider that some verifications like inspections and formal proofs are done at a point in time and then need to be repeated every time the production code changes, whereas unit tests and assertions can be used as regression tests (written once and executed repeatedly thereafter). Sometimes I agree with them, but more often I will debate about whether a method is really too simple or too difficult to unit test. If a developer argues that a method seems too simple to fail, isn't it worth taking the 60 seconds necessary to write up a simple 5-line unit test for it? These 5 lines of code will run every night (you do nightly builds, right?) for the next year or more and will be worth the effort if even just once it happens to catch a problem that may have taken 15 minutes or longer to identify and debug. Besides, writing the easy unit tests drives up the count of unit tests, which makes the developer look good. On the other hand, if a developer argues that a method seems too difficult to unit test (not worth the significant effort required), perhaps that is a good indication that the method needs to be divided up or refactored to test the easy parts. Usually, these are methods that rely on unusual resources like singletons, the current time, or external resources like a database result set. These methods usually need to be refactored into a method that gets the resource (e.g. calls getTime()) and a method that takes the resource as a argument (e.g. takes the timestamp as a parameter). I let them skip testing the method that retrieves the resource and they instead write a unit test for the method that now takes the resource as a argument. Usually, this makes writing the unit test much simpler and therefore worthwhile to write. The developer needs to draw a "line in the sand" in how comprehensive their unit tests should be. Later in development, whenever we find a bug, they should determine if more comprehensive unit tests would have caught the problem. If so and if such bugs crop up repeatedly, they need to move the "line" toward writing more comprehensive unit tests in the future (starting with adding or expanding the unit test for the current bug). They need to find the right balance.

重要的是要认识到单元测试并不是万能的，而且存在太多单元测试这样的事情。在我的工作场所，每当我们做一个经验教训，我不可避免地听到“我们需要写更多的单元测试”。管理层点头表示同意，因为“单元测试”==“好”这句话已经被灌输到他们的头脑中了。

However, we need to understand the impact of "more unit tests". A developer can only write ~N lines of code a week and you need to figure out what percentage of that code should be unit test code vs production code. A lax workplace might have 10% of the code as unit tests and 90% of the code as production code, resulting in product with a lot of (albeit very buggy) features (think MS Word). On the other hand, a strict shop with 90% unit tests and 10% production code will have a rock solid product with very few features (think "vi"). You may never hear reports about the latter product crashing, but that likely has as much to do with the product not selling very well as much as it has to do with the quality of the code.

Worse yet, perhaps the only certainty in software development is that "change is inevitable". Assume the strict shop (90% unit tests/10% production code) creates a product that has exactly 2 features (assuming 5% of production code == 1 feature). If the customer comes along and changes 1 of the features, then that change trashes 50% of the code (45% of unit tests and 5% of the production code). The lax shop (10% unit tests/90% production code) has a product with 18 features, none of which work very well. Their customer completely revamps the requirements for 4 of their features. Even though the change is 4 times as large, only half as much of the code base gets trashed (~25% = ~4.4% unit tests + 20% of production code).

我的观点是你必须传达你理解单元测试太少和太多之间的平衡——本质上你已经考虑了问题的两面。如果你能说服你的同事和/或你的管理层，你就获得了信誉，也许就有更好的机会赢得他们的信任。

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

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

测试驱动开发中经常被忽略的一个主要部分是可测试代码的编写。乍一看，这似乎是一种妥协，但您会发现可测试代码最终也是模块化的、可维护的和可读的。 如果你仍然需要说服别人，这是一个关于单元测试优点的简单演示。