这当然预设了单元测试是一件好事。我们的项目有一定程度的单元测试，但充其量是不一致的。
您曾经使用过或曾经与您一起使用过的最令人信服的方法是什么让每个人相信形式化的单元测试是一件好事，并且需要它确实符合我们从事的“大型”项目的最佳利益。我不是开发人员，但我从事质量保证工作，并希望提高所交付工作的质量，以确保它可以进行测试。
通过形式化的单元测试，我只是在谈论
- 确定要编写的单元测试
- 识别测试数据（或描述它）
- 编写这些测试
- 跟踪这些测试（并根据需要重新使用）
- 使结果可用
not-bob
问问题
498 次
14 回答
4
一个非常有说服力的方法是自己进行形式化的单元测试，无论您的团队/公司做什么。这可能需要您付出一些额外的努力，特别是如果您没有这种练习的经验。
当你可以展示你的代码更好并且你比其他开发人员更有效率时，他们会想知道为什么。然后向他们提供您最喜欢的单元测试方法。
一旦你说服了你的开发人员，一起说服管理层。
于 2008-09-23T11:42:25.100 回答
4
我将Maven与Surefire和Cobertura插件一起用于我的所有构建。实际的测试用例是使用JUnit、DbUnit和EasyMock创建的。
识别单元测试 我尝试遵循测试驱动开发，但老实说，我通常只为少数测试用例执行此操作，然后再回来为边缘和异常用例创建测试。
识别测试数据 DbUnit 非常适合为您的单元测试加载测试数据。
编写测试用例 我使用 JUnit 来创建测试用例。我尝试编写自我记录的测试用例，但会使用 Javadocs 来注释一些不明显的东西。
跟踪并使结果可用 我使用 Surefire 插件将单元测试集成到我的 Maven 构建周期中，并使用 Corbertura 插件来测量这些测试实现的覆盖率。我总是生成并发布一个包含 Surefire 和 Cobertura 报告的网站，作为我日常构建的一部分，这样我就可以看到哪些测试失败/通过了。
于 2008-09-23T11:52:53.733 回答
2
让我信服的事件是当我们在连续三个版本中成功地对一个错误进行了三次回归时。一旦我意识到我作为一名程序员的工作效率是多么高，当我在客户提交给客户后不再不断地修复琐碎的错误时，我会产生一种温暖的模糊感觉，即同事的代码会按照他们声称的那样做，我就变成了一个皈依者。
于 2008-09-23T11:41:28.753 回答
2
早在我在大型机上进行 Cobol 开发的那一天，我们在我工作的几家公司中都虔诚地这样做了，并且由于环境强制执行它，它被接受为你做事的方式。我认为这是那个时代非常典型的方案，也许其中一些原因可能适用于你：-
像大多数大型机环境一样，我们有三个领域，开发、质量保证和生产。程序员在开发中开发并在那里进行单元测试，一旦他们签署并满意，该单元就会迁移到 QA 环境（带有测试和结果文档），在那里由专门的 QA 人员进行系统测试。向 QA 迁移的开发是一夜之间发生的正式步骤。一旦 QA'ed 代码被迁移到生产环境——我们几乎没有错误。
完成并正确进行单元测试的动机是，如果你没有完成并且 QA 人员发现了一个错误，那么很明显你没有完成这项工作。因此，您的声誉取决于您的严谨程度。当然，大多数人最终会遇到偶尔出现的错误，但是那些一直编写可靠的测试代码的编码人员很快就获得了明星声誉，那些编写有错误代码的人也受到了关注。推动力始终是为了提升您的游戏水平，因此所产生的文化是推动第一次交付无错误代码的文化。
提取相关点 -
- 编码员的声誉与交付无错误的测试代码有关
- 与将单元测试代码移动到下一个级别相关的大量开销，因此有动力不要重复这一点并在第一时间把它做好。
- 由不同的人对单元测试执行系统测试——最好是不同的团队。
我相信您的环境会有所不同，但原则可能是可翻译的。
于 2008-09-23T11:59:30.037 回答
1
教育和/或认证。
为您的团队成员提供测试领域的正式培训——也许通过认证考试（取决于您的团队成员和您自己对认证的态度）。通过这种方式，您将把测试提升到一个更高的水平，您的团队成员将更有可能对测试采取专业的态度。
于 2008-09-23T11:47:35.853 回答
1
有时以身作则是最好的方法。我还发现提醒人们某些事情在测试时不会发生。下次有人要求你写东西时，不管怎样，用测试来做。最终，您的同行会嫉妒您可以轻松更改代码并知道它仍然有效。
至于管理，您需要强调当您需要对未测试的代码库 X 进行更改时，由于发生核爆炸而浪费了多少时间。
许多开发人员在没有确保他们在整个系统中保留行为的情况下没有意识到他们重构了多少。对我来说，这是我认为单元测试和 TDD 的最大好处。
- 软件需求变更
- 软件更改以适应要求
唯一确定的是变化。更改未测试的代码要求开发人员了解可能的每一种行为副作用。现实情况是，那些认为他们可以读懂每一个排列的编码人员，都是通过痛苦的试错过程来做到这一点的，直到没有明显的中断。此时他们登记入住。
务实的程序员认识到他/她并不完美且无所不知，而测试就像一张安全网，可以让他们快速安全地走重构的钢丝。
至于何时对新代码编写测试，我必须尽可能多地提倡。花时间定义您希望系统产生的行为，并最初编写测试以表达那些更高级别的构造。单元测试可以随着思想的结晶而出现。
希望这可以帮助。
于 2008-09-23T11:49:32.617 回答
1
说服和要求之间有很大的区别。
如果你找到一种方法来说服你的同事写它们 - 太好了。但是，如果您创建一些形式化的规则并要求他们编写单元测试，他们会找到克服这个问题的方法。结果，您将获得一堆毫无价值的单元测试：每个可用的类都将进行单元测试，它们将测试 setter 和 getter。
在创建和执行规则之前三思而后行。开发人员擅长克服它们。
于 2008-09-23T12:30:02.553 回答
0
提醒您的团队或其他开发人员他们是专业人士，而不是业余爱好者。为我工作！
此外，它是当今的行业标准。如果没有单元测试经验，对于潜在的未来雇主来说，它们作为雇员的吸引力和价值都较低。
于 2008-09-23T11:40:51.483 回答
0
第一次你只需要继续写它们并向人们展示它是值得的。我在三个项目中发现这是说服人们的唯一方法。一些不编码的人（例如初级项目经理）将无法看到价值，直到它正视他们的脸。
于 2008-09-23T11:41:27.363 回答
0
在我的软件团队中，我们倾向于针对这些问题编写一个小型商业案例并将其提交给管理层，以便有时间创建和跟踪测试。我们解释说，当关键时刻到来并且一切都在线时，测试所花费的时间得到了很好的弥补。我们还设置了一个 Hudson 构建服务器来集中跟踪单元测试。这使开发人员更容易跟踪失败的测试并发现重复出现的问题。
于 2008-09-23T11:42:53.353 回答
0
作为团队负责人，我有责任确保我的程序员对他们工作的所有模块进行单元测试。我想在这一点上，这甚至不是如何说服他们的问题，这是必需的。有时不是，不是在大型项目上，一直都是。单元测试是防止将必须维护的东西投入生产的第一道防线。如果将某些尚未完全单元和系统测试的东西投入生产，那么它会回来咬你。我想我们在这里支持这一点的政策之一是，如果它在生产中发生故障或导致问题，那么负责编码和测试该模块的程序员将是必须解决问题的人，进行清理等等。仅此一项就是一个很好的动力。
另一个是关于骄傲。我在一家大约有 75 名编码员的商店工作，虽然按某些标准来说这很大，但它真的很小，足以让我们所有人都互相认识。它也足够小，我们知道彼此在做什么，当它进入生产时，我们知道任何异常终止、故障等。如果你小心，做单元和系统测试，移动某物的机会在不引起故障的情况下生产量显着增加。将某些东西投入生产并未能实现可能需要一两次时间，但不搞砸会带来巨大的回报。当您搬入一个项目并且它没有搞砸时，在走廊里听到祝贺真是太好了。
于 2008-09-23T12:02:51.493 回答
0
写一堆，证明单元测试提高了你的生产力和代码的质量。如果没有某种证据，有时人们不会相信这是值得的。
于 2008-09-23T12:49:42.800 回答
0
因此，在我提出这个问题两年后，我发现一个出乎意料的答案是，需要迁移到新的 SDLC。五年前，我们建立了第一个正式的 SDLC。它改善了我们的情况，但遗漏了一些重要的事情，例如自动化。我们现在正在建立一个新的 SDLC（在新的管理下），其中一个租户是自动化的。不仅仅是自动化的单元测试，还有自动化的功能测试。
我想教训是我想得太小了。如果你要改变你创建软件的方式，那就“全力以赴”并做出巨大的改变，而不是在你不习惯的情况下提出渐进式的改变。
于 2010-10-15T15:02:01.960 回答
0
您可以从 Google 的一项计划中获得一些灵感。他们的测试团队开始在厕所隔间内放置示例、提示和好处，以提高测试自动化优点的知名度。
https://testing.googleblog.com/2007/01/introducing-testing-on-toilet.html
于 2019-04-10T06:01:19.260 回答