要求正式单元测试最有说服力的方式是什么？

StackOverflow https://stackoverflow.com/questions/120460

  •  02-07-2019
  •  | 
  •  

题

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

您使用过或与您一起使用过的最有说服力的方法是什么，可以让每个人相信形式化的单元测试是一件好事，并且将其作为必需的确实符合我们所从事的“大型”项目的最佳利益。我不是开发人员，但我从事质量保证工作，希望提高所交付工作的质量，以确保其准备好进行测试。

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

  • 确定要编写的单元测试
  • 识别测试数据（或描述它）
  • 编写这些测试
  • 跟踪这些测试（并根据需要重新使用）
  • 提供结果
有帮助吗？

解决方案 13

因此，在我提出这个问题两年后，我发现一个意想不到的答案是，迁移到新的 SDLC 正是我们所需要的。五年前，我们建立了第一个正式的 SDLC。它改善了我们的情况，但遗漏了一些重要的事情，例如自动化。我们现在正在建立一个新的 SDLC（在新的管理下），其中的租户之一是自动化。不仅仅是自动化单元测试，还有自动化功能测试。

我想教训是我想得太小了。如果您要改变创建软件的方式，请“全力以赴”并进行彻底的更改，而不是在您不习惯的情况下提出增量更改。

其他提示

一个非常令人信服的方法是自己进行正式的单元测试，无论您的团队/公司做什么。这可能需要您付出一些额外的努力，特别是如果您没有这种练习的经验。

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

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

我用 梅文 与 万无一失 和 科贝尔图拉 我所有构建的插件。实际的测试用例是用以下命令创建的 联合单元, 数据库单元 和 易模拟.

识别单元测试我尝试遵循测试驱动开发，但说实话，我通常只对少数测试用例执行此操作，然后再回来为边缘和异常情况创建测试。

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

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

跟踪并提供结果我使用 Surefire 插件将单元测试集成到我的 Maven 构建周期中，并使用 Corbertura 插件来测量这些测试所实现的覆盖率。我总是生成并发布一个网站，其中包括 Surefire 和 Cobertura 报告，作为我日常构建的一部分，这样我就可以看到哪些测试失败/通过了。

让我信服的事件是我们在连续三个版本中成功地使错误回归了三次。一旦我意识到，作为一名程序员，如果我不在客户那里不断地修复琐碎的错误，那么我的工作效率会提高多少，而且我可能会有一种温暖的模糊感觉，同事的代码会按照他们声称的那样做，我就变得一个皈依者。

回到我在大型机上进行 Cobol 开发的那一天，我们在我工作过的几家公司中虔诚地这样做，并且它被接受为你做事的方式，因为环境强制执行它。我认为这是那个时代非常典型的方案，也许其中一些原因可能适用于您：-

与大多数大型机环境一样，我们有三个领域：开发、质量保证和生产。程序员在那里进行开发和单元测试，一旦他们签字并感到高兴，该单元就会迁移到 QA 环境（带有测试和结果文档），由专门的 QA 人员对其进行系统测试。QA 迁移的开发是一夜之间发生的正式步骤。一旦经过质量检查，代码就会迁移到生产环境 - 我们几乎没有错误。

正确完成单元测试的动机是，如果您没有这样做并且 QA 人员发现了错误，那么很明显您没有完成这项工作。因此，你的声誉取决于你的严谨程度。当然，大多数人最终都会遇到偶尔的错误，但是始终生成可靠的经过测试的代码的程序员很快就会获得明星声誉，而那些生成有错误的代码的人也会受到关注。推动力始终是提高你的游戏水平，因此产生的文化是推动第一次交付无错误代码的文化。

提取相关点 -

  1. 编码员的声誉与交付无错误的测试代码息息相关
  2. 将单元测试代码移至下一个级别会带来巨大的开销，因此不要重复此操作并第一次就做对。
  3. 系统测试由不同的人执行到单元测试 - 最好是不同的团队。

我确信您的环境会有所不同，但原理可能是可以翻译的。

有时以身作则是最好的方法。我还发现，这提醒人们，当事情处于测试阶段时，某些事情就不会发生。下次有人要求你写一些东西时，无论如何都要进行测试。最终，你的同事会嫉妒你可以轻松地更改代码并知道它仍然有效。

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

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

  1. 软件需求变化
  2. 软件更改以满足要求

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

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

至于何时在新代码上编写测试，我必须尽可能地提倡。花时间定义 行为 您希望从系统中删除这些内容，并首先编写测试来表达那些更高级别的构造。当想法具体化时，单元测试就会随之而来。

希望这可以帮助。

教育和/或认证。

为您的团队成员提供测试领域的正式培训 - 也许包括认证考试（取决于您的团队成员和您自己对认证的态度）。通过这种方式，您将把测试提升到更高的水平，并且您的团队成员将更有可能对测试采取专业的态度。

之间有很大的区别 令人信服的 和 要求.

如果你找到一种方法说服你的同事来写它们——那就太好了。但是，如果您创建一些正式的规则并要求他们编写单元测试，他们会找到一种方法来克服这个问题。结果你会得到一堆毫无价值的单元测试：每个可用的类都会进行单元测试，并且他们将测试 setter 和 getter。

在制定和执行规则之前要三思而后行。开发人员善于克服这些问题。

第一次，你只需要继续写下来，并向人们展示这是值得的。我在三个项目中发现这是说服人们的唯一方法。有些人不编码（例如初级项目经理）只有在它摆在面前时才能看到其价值。

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

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

此外，它现在已成为行业标准。如果没有单元测试经验，对于未来的潜在雇主来说，他们作为雇员的吸引力和价值就会降低。

作为团队领导，我有责任确保我的程序员对他们工作的所有模块进行单元测试。我想在这一点上，这甚至不是如何说服他们的问题，这是必需的。有时候不是，大型项目也不是，总是如此。单元测试是防止将某些东西投入生产而需要维护的第一道防线。如果某些东西投入生产时还没有经过完全的单元和系统测试，那么它就会回来咬你。我想我们支持这一点的政策之一是，如果它在生产中崩溃，或者导致问题，那么负责编码和测试该模块的程序员将是必须处理问题、进行清理的人， ETC。仅此一点就是一个相当好的激励因素。
另一个是关于骄傲。我在一家大约有 75 名编码员的商店工作，尽管从某些标准来看这个规模很大，但它确实小到足以让我们所有人互相认识。它也足够小，我们知道彼此正在做什么，当它投入生产时，我们会意识到任何异常终止、失败等。如果您小心地进行单元和系统测试，那么将某些东西转移到生产环境而不导致故障的机会就会大大增加。将某些东西投入生产可能需要一两次时间，但未能实现，但不搞砸会带来巨大的回报。当你把一个项目搬进去并且没有搞砸时，在走廊里听到祝贺真是太好了。

编写一堆单元测试并证明单元测试提高了您的生产力和代码质量。如果没有某种证据，有时人们不会相信这是值得的。

您可以从 Google 的一项举措中获得一些灵感。他们的测试团队开始在厕所隔间内张贴示例、技巧和好处，以提高测试自动化优点的形象。

https://testing.googleblog.com/2007/01/introducing-testing-on-toilet.html

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top