这当然以单元测试是一件好事为前提。我们的项目具有一定水平的单元测试，但充其量是不一致的。

我们使用或者曾经与我们一起使用过的最有说服力的方法是，使每个人都相信正规的单元测试是一件好事，而使其成为必需品确实符合我们正在从事的"大型"项目的最大利益。我不是开发人员，但是我有质量保证，因此希望提高交付的工作质量，以确保可以进行测试。

通过正式的单元测试，我只是在谈论

• 确定要编写的单元测试
• 识别测试数据(或者描述它)
• 编写这些测试
• 跟踪这些测试(并根据需要重复使用)
• 使结果可用

解决方案

提醒团队或者其他开发人员，他们是专业人士，而不是业余爱好者。为我工作！

而且，这是当今的行业标准。没有单元测试经验，它们对于潜在的未来雇主而言就不那么理想，也就没有价值。

第一次学习时，我们只需要继续写它们，并向人们表明这是值得的。我在三个项目中发现，这是说服人们的唯一方法。某些不进行编码的人(例如初级项目经理)将无法看到其价值，除非它直面他们。

令我信服的事件是，我们连续三个版本成功解决了3次bug。当我意识到当我去解决客户遇到的小错误后，我并没有不断修正这些琐碎的错误时，我作为一名程序员的工作效率提高了，我可能会产生一种模糊的感觉，即同事的代码将按照他们的要求去做，一个转换。

一个非常有说服力的方法是对自己进行正式的单元测试，而不管团队/公司做什么。这可能需要我们付出额外的精力，特别是如果我们没有这种实践经验的话。

然后，当我们可以证明自己的代码更好，并且效率比其他开发人员更高时，他们就会想知道为什么。然后为他们提供我们喜欢的单元测试方法。

一旦说服了其他开发人员，就一起说服管理层。

在我的软件团队中，我们倾向于编写有关这些问题的小型业务案例，并将其呈现给管理层，以便有时间创建和跟踪测试。我们解释说，当关键时刻到来时一切都准备就绪，测试所需的时间就得到了很好的弥补。我们还设置了一个Hudson构建服务器，以集中跟踪单元测试。这使开发人员更容易跟踪失败的测试并发现重复出现的问题。

教育和/或者认证。

可以通过认证考试为团队成员提供有关测试领域的正式培训(取决于团队成员和我们自己对认证的态度)。我们将以这种方式将测试提升到更高的水平，并且团队成员将更有可能对测试采取专业态度。

有时以身作则是最好的方法。我还发现，这提醒人们某些事情在测试中不会发生。下次有人要我们写东西时，无论如何都要用测试来做。最终，同事会嫉妒我们更改代码并知道它仍然有效的便捷性。

至于管理，我们需要强调由于需要对未测试的代码库X进行更改时发生的核爆炸而浪费了多少时间。

许多开发人员在没有确保自己在整个系统中保持行为的情况下才意识到他们重构了多少东西。对我来说，这对单元测试和TDD来说是最大的好处。

• 软件需求变更
• 更改软件以符合要求

唯一可以确定的是变化。更改未经测试的代码要求开发人员意识到所有可能的行为副作用。现实情况是，认为自己可以读入每个排列的编码人员都是通过反复试验的艰苦过程来做到这一点的，直到没有明显的问题为止。此时，他们将签入。

务实的程序员认识到他/她并不完美，并且一无所知，并且测试就像一个安全网，可以使他们快速安全地走过重构钢丝。

至于何时编写未开发代码的测试，我必须尽可能提倡。花时间定义系统中想要的行为，并最初编写测试来表达那些更高层次的构造。单元测试可以随心所欲而来。

希望这可以帮助。

我将Maven与Surefire和Cobertura插件一起用于所有构建。实际的测试用例是使用JUnit，DbUnit和EasyMock创建的。

识别单元测试
我尝试遵循测试驱动开发，但老实说，我通常只是针对少数几个测试用例进行测试，然后再回来为边缘和异常用例创建测试。

识别测试数据
DbUnit非常适合为单元测试加载测试数据。

编写测试用例
我使用JUnit创建测试用例。我尝试编写自我记录测试用例，但将使用Javadocs注释一些不明显的内容。

跟踪并提供结果
我使用Surefire插件将单元测试集成到我的Maven构建周期中，并使用Corbertura插件来衡量这些测试所达到的覆盖率。我每天都会生成并发布一个包含Surefire和Cobertura报告的网站，这是我日常工作的一部分，因此我可以查看哪些测试失败/通过了。

那天我在大型机上进行Cobol开发时，我们虔诚地在我工作过的几家公司中做到了这一点，并且由于环境的要求，它被视为我们做事的方式。我认为这是那个时代非常典型的方案，也许某些原因可能适用于我们：-

像大多数大型机环境一样，我们有三个领域，即开发，质量保证和生产。程序员在开发中进行开发，并在那里进行了单元测试，一旦他们签字并感到满意，他们就很高兴将单元迁移到QA环境(带有测试和结果文档)中，并由专门的QA人员对其进行系统测试。向QA迁移的开发是一个正式的步骤，在一夜之间发生了。进行质量检查后，代码便迁移到了生产环境，而我们的bug很少。

正确完成单元测试的动机是，如果我们没有这样做，并且质量检查人员发现了错误，则很明显我们没有完成工作。因此，声誉取决于严格程度。当然，大多数人最终都会遇到偶然的错误，但是一直生产可靠的经过测试的代码的编码人员很快就赢得了声誉，而产生错误的代码的编码人员也受到了关注。推动力始终是提高游戏水平，因此，产生的文化是推动首次交付的无错误代码的文化。

提取相关点-

• 编码器声誉与无bug测试代码的交付息息相关
• 与将单元测试的代码移至下一级别相关的大量开销，因此请不要重复执行此操作并使其第一次正确使用。
• 系统测试由不同的人员执行，以进行单元测试-最好是由不同的团队进行。

我确定环境会有所不同，但是主体可能是可翻译的。

作为团队负责人，我有责任确保程序员对所有工作模块进行单元测试。我想在这一点上，这甚至不是如何说服他们的问题，这是必需的。有时候，并非总是如此，不是在大型项目上。单元测试是防止将必须维护的产品投入生产的第一道防线。如果投入生产的产品尚未经过完全的单元和系统测试，那么它会再次咬住我们。我想我们这里要支持的策略之一是，如果它在生产中引起轰动或者引起问题，那么负责编码和测试该模块的程序员将是必须解决这些问题的人员，请执行清理工作。等等。这本身就是一个相当不错的激励因素。
另一个是关于骄傲。我在大约75位编码员的商店里工作，尽管按某些标准来说这是很大的，但它的规模确实很小，我们所有人都可以相互了解。它也足够小，我们可以知道彼此之间正在做什么，并且当它移至生产中时，我们会知道任何异常，故障等。如果我们小心一点，请进行单元和系统测试，以及进行某些移动的机会在不造成故障的情况下投入生产的时间大大增加。将某件产品投入生产并没有意识到可能要花费一两个时间，但是不弄乱它们会带来巨大的回报。当我们将项目移入而不会弄糟时，听到走廊上的祝贺真是太好了。

说服和要求之间有很大的区别。

如果我们找到一种方法说服同事给他们写很棒的话。但是，如果我们创建一些形式化的规则并要求他们编写单元测试，则他们将找到一种克服此问题的方法。结果，我们将获得一堆毫无价值的单元测试：每个可用的类都会有单元测试，并且它们将测试setter和getter。

在创建和执行规则之前，请三思。开发人员擅长克服它们。

写一堆，并证明单元测试可以提高生产率和代码质量。没有某种证据，有时人们会认为这是不值得的。

因此，在我问了这个问题两年后，我发现一个出乎意料的答案是，需要迁移到新的SDLC。五年前，我们建立了第一个正式的SDLC。它改善了我们的处境，但是省略了一些重要的事情，例如自动化。我们现在正在建立新的SDLC(在新的管理之下)，其中租户之一是自动化。不仅是自动化的单元测试，还包括自动化的功能测试。

我想这课是我想的太小了。如果我们要更改软件的创建方式，请"全力以赴"并进行彻底的更改，而不是建议我们进行增量更改(如果我们不习惯的话)。