多年来，我一直试图说服人们，他们需要为自己的代码编写单元测试。无论他们是先编写测试(如TDD)还是在编写功能之后，我总是试图向他们解释对代码进行单元测试的所有好处。几乎没有人反对我。你不能否认一些显而易见的事情，任何聪明的人都会看到单元测试和TDD的好处。

单元测试的问题在于它需要行为上的改变，而要改变人们的行为是非常困难的。用语言，你会让很多人同意你的观点，但你不会看到他们做事的方式有太多变化。

你必须通过行动来说服人们。你的个人成功会比你的争论吸引更多的人。如果他们看到你不只是在谈论单元测试或TDD，而是在做你鼓吹的事情，而且你是成功的，人们就会试图模仿你。

You should also take on a lead role because no one writes unit test right the first time, so you may need to coach them on how to do it, show them the way, and the tools available to them. Help them while they write their first tests, review the tests they write on their own, and show them the tricks, idioms and patterns you've learned through your own experiences. After a while, they will start seeing the benefits on their own, and they will change their behavior to incorporate unit tests or TDD into their toolbox.

改变不会在一夜之间发生，但只要有一点耐心，你就可能实现你的目标。

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

让你测试的第一个东西与单元测试无关。我主要使用Perl工作，所以这些都是特定于Perl的示例，但您也可以适应。

每个模块是否正确加载和编译?在Perl中，这是一个创建Foo的问题。t对每个Foo。PM的代码库，它做: use_ok('Foo'); 所有的POD(普通文档)格式是否正确?使用Test::Pod来验证所有文件中所有Pod格式的有效性。

你可能不认为这些是大事情，他们不是，但我可以保证你会抓到一些泔水。当这些测试每小时运行一次，并捕捉到某人的过早提交时，您会让人们说“嘿，这很酷”。

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.

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

你想说服谁?工程师还是经理?如果你试图说服你的工程师同事，我认为你最好的办法是迎合他们的愿望，让他们做出高质量的软件。有许多研究表明，它能发现漏洞，如果他们关心做好工作，这对他们来说就足够了。

如果您试图说服管理层，您将很可能不得不做一些成本/收益推理，说明未检测到的缺陷的成本大于编写测试的成本。一定要把不可转化的成本也包括在内，比如失去客户的信心等等。

我在几年前发现了TDD，从那时起我就使用它编写了所有我喜欢的项目。我估计，TDD一个项目所花费的时间与牛仔式地组合一个项目所花费的时间大致相同，但我对最终产品的信心增加了，以至于我忍不住有一种成就感。

我还觉得它改进了我的设计风格(更面向界面，以防我需要一起模拟东西)，而且，正如顶部的绿色帖子所写的，它有助于“编码便秘”:当你不知道接下来要写什么，或者你有一个令人生畏的任务摆在你面前时，你可以写小一点的。

最后，我发现到目前为止，TDD最有用的应用是在调试中，如果仅仅因为您已经开发了一个询问框架，那么您就可以用它来刺激项目以可重复的方式产生错误。