这当然预示着单元测试是一件好事。我们的项目有一定程度的单元测试，但最好不一致。
您使用或曾经使用过哪些最有说服力的方法来说服每个人正式的单元测试是一件好事，并且需要它才能真正符合我们工作的'大型'项目的最佳利益。我不是开发人员，但我从事质量保证工作，并希望提高工作质量，以确保其准备好进行测试。
通过正式的单元测试，我只是在谈论
答案 0 :(得分：4)
一种非常有说服力的方法是自己进行正式的单元测试，无论您的团队/公司做什么。这可能需要一些额外的努力，特别是如果你没有这种练习的经验。
当你可以展示你的代码更好，并且你比其他开发人员更有效率时，他们会想知道原因。然后喂他们最喜欢的单元测试方法。
一旦你说服了你的开发人员，就一起说服管理层。
答案 1 :(得分：4)
我对Maven和Surefire插件使用Cobertura进行所有构建。实际的测试用例是使用JUnit，DbUnit和EasyMock创建的。
识别单元测试 我尝试遵循测试驱动开发，但说实话，我通常只是为少数几个测试用例做到这一点，然后再回来为边缘和异常情况创建测试。
识别测试数据 DbUnit非常适合加载单元测试的测试数据。
编写测试用例 我使用JUnit来创建测试用例。我尝试编写自我记录的测试用例，但会使用Javadocs来评论一些不明显的东西。
追踪＆amp;使结果可用 我使用Surefire插件将单元测试集成到我的Maven构建周期中，并使用Corbertura插件来测量这些测试所实现的覆盖范围。我总是生成并发布一个网站，其中包括Surefire和Cobertura报告，作为我日常构建的一部分，因此我可以看到哪些测试失败/通过。
答案 2 :(得分：2)
让我信服的事件是，当我们连续三次发布时，我们设法三次回归一个错误。有一次我意识到，作为一名程序员，当我们去客户端之后并没有经常解决琐碎的错误时，我的工作效率会提高多少，而且我可以有一种温暖的模糊感觉，即同事代码会做他们声称的那样，我成了转换。
答案 3 :(得分：2)
当我在Mainframes上进行Cobol开发的那一天，我们在我工作的几家公司中虔诚地做了这件事，并且因为环境强制执行它而被接受为你做事的方式。我认为这是一个非常典型的时代计划，也许有些原因可能适用于你： -
与大多数大型机环境一样，我们有三个领域，即开发，质量保证和生产。程序员在开发中开发并在那里进行单元测试，一旦他们签约并且很高兴，该单元就被迁移到QA环境（带有测试和结果文档），由专业的QA人员进行系统测试。 QA迁移的发展是一个在一夜之间发生的正式步骤。一旦质量问题，代码就会迁移到生产 - 我们的错误很少。
完成单元测试的动机是正确的，如果你没有，并且质量保证人员发现了一个错误，很明显你没有完成这项工作。因此，你的声誉取决于你的严谨程度。当然，大多数人最终都会遇到偶然的错误，但是编写完整测试代码的编码员很快就获得了明星声誉，那些制作错误代码的人也受到了关注。推动将始终是你的游戏，因此产生的文化是推动第一次提供的无错代码。
提取相关要点 -
我确信您的环境会有所不同，但主体可能是可翻译的。
答案 4 :(得分：1)
教育和/或认证。
为您的团队成员提供测试领域的正式培训 - 可能通过认证考试（取决于您的团队成员和您对认证的态度）。您将以这种方式将测试提升到更高的水平，并且您的团队成员将更有可能采取专业的态度进行测试。
答案 5 :(得分：1)
有时通过示例是最好的方法。我也发现提醒人们，当事情受到考验时，某些事情就不会发生。下次有人要求你写东西时，无论如何都要做测试。最终，您的同行会嫉妒您可以轻松更改代码并知道它仍然有效。
至于管理，您需要强调，当您需要对未经测试的代码库X进行更改时会发生核爆炸会浪费多少时间。
许多开发人员没有意识到他们重构了多少而没有确保他们在整个系统中保留行为。对我来说，这是我认为单元测试和TDD的最大好处。
唯一确定的是改变。更改未测试的代码需要开发人员了解可能的每个行为副作用。现实情况是那些认为他们可以读入每个排列的程序员，通过一个痛苦的试错过程来做到这一点，直到没有任何明显的破坏。此时他们办理登机手续。
务实的程序员认识到他/她并不完美而且都知道，而且测试就像一个安全网，可以让他们快速安全地走完重构走钢丝。
至于何时在绿地代码上编写测试，我必须尽可能地提倡。花时间定义您想要的行为，并最初编写测试来表达那些更高级别的结构。思想结晶可以产生单元测试。
希望这有帮助。
答案 6 :(得分：1)
令人信服的与需要之间存在很大差异。
如果你找到一种方法来说服你的同事写出来 - 那很好。但是，如果您创建一些正式规则并要求它们编写单元测试，他们将找到克服此问题的方法。因此，您将获得一系列无价值的单元测试：每个可用的类都将进行单元测试，他们将测试setter和getters。
在创建和实施规则之前请三思而后行。开发人员善于克服它们。
答案 7 :(得分：0)
提醒您的团队或其他开发人员他们是专业人士，而不是业余爱好者。为我工作！
此外，它现在是行业标准。如果没有单元测试经验，那么作为潜在未来雇主的员工，他们就不那么可取，也不那么有价值了。
答案 8 :(得分：0)
第一次你只需要继续写下来并向人们展示它是值得的。我在三个项目中发现，这是说服人们的唯一方法。一些不编码的人（例如初级项目经理）在看到他们面对面之前将无法看到价值。
答案 9 :(得分：0)
在我的软件团队中，我们倾向于针对这些问题编写一个小型商业案例，并将其呈现给管理层，以便有时间创建和跟踪测试。我们解释说，测试所花费的时间很好地弥补了关键时刻的到来以及一切都在线上。我们还设置了一个Hudson构建服务器来集中跟踪单元测试。这使得开发人员更容易跟踪失败的测试并发现重复出现的问题。
答案 10 :(得分：0)
作为团队负责人，我有责任确保我的程序员对他们所处理的所有模块进行单元测试。我想在这一点上，它甚至不是一个如何说服他们的问题，这是必需的。有时候，不是一直在大型项目上。单元测试是防止生产必须维护的第一道防线。如果某些产品没有经过完整的单元和系统测试，那么它会回来咬你。我想我们在这里支持的一个策略是，如果它在生产中爆炸或导致问题，那么负责编码和测试该模块的程序员将是必须处理问题的程序，进行清理等等。这是一个相当好的动力 另一个是它是关于骄傲。我在一家大约75名程序员的工作中工作，尽管按照某些标准来说这很大，但它确实足够小，我们所有人都可以相互认识。它也足够小，我们知道彼此正在做什么，当它转移到生产时，我们知道任何异常，失败等。如果你小心，做单元和系统测试，移动东西的机会生产不会导致失败显着增加。可能需要一两年的时间才能将某些东西转移到生产中并且没有意识到这一点，但是有很多奖励涉及不搞乱。当你搬进一个项目的时候听到走廊里的祝贺真是太好了，它并没有搞砸。
答案 11 :(得分：0)
写下一堆，并证明单元测试提高了您的工作效率和代码质量。如果没有某种证据，有时人们会认为不值得。
答案 12 :(得分：0)
所以，在我提出这个问题两年后，我发现一个意想不到的答案是，通过转移到新的SDLC是需要的。五年前，我们建立了第一个正式的SDLC。它改善了我们的情况，但遗漏了一些重要的事情，比如自动化。我们现在正在建立一个新的SDLC（在新的管理下），其中一个租户是自动化的。不仅是自动化单元测试，还包括自动化功能测试。
我想我的教训是我的想法太小了。如果您要改变创建软件的方式，那就去“整体生活”并做出重大改变，而不是提出改变，如果你不习惯这样做的话。
答案 13 :(得分：0)
您可以从Google的一项举措中获得一些启发。他们的测试团队开始在厕所隔间内放置示例，技巧和好处，以提高测试自动化的优点。
https://testing.googleblog.com/2007/01/introducing-testing-on-toilet.html