在不这样做的公司中实施单元测试

我公司的软件开发负责人只是“辞职”（即被解雇），我们现在正在研究改善公司的开发实践。我们希望在以后创建的所有软件中实施单元测试。

开发人员的反馈是：

• 我们知道测试很有价值
• 但是，您总是在更改规格，因此会浪费时间
• 而且，您的截止日期太紧了，我们还是没有足够的时间进行测试

CEO的反馈是：

• 我希望我们的公司进行自动化测试，但我不知道如何实现
• 我们没有时间编写大型规范文档

开发人员现在如何获得规格？口耳相传或PowerPoint幻灯片。显然，这是一个大问题。我的建议是这样的：

• 我们还为开发人员提供一组测试数据和单元测试
• 那是规格。管理层需要清楚，定量地了解其需求。
• 开发人员可以将其认为需要的任何其他功能放入测试中，而无需测试

好吧，如果您曾经在一家处于这种情况的公司任职，那么您是如何解决问题的？这种方法看起来合理吗？

看来您正在混合两种不同的测试：单元测试和系统/验收测试。前者在较低级别上运行，测试小段代码（通常是单独的方法），这些代码通常位于程序内部深处，用户无法直接看到它们。后者以更高的粒度级别测试用户所看到的整个程序。因此，只有后者可以基于任何形式的系统规范。

将这两个问题分开，就可以轻松地开始着手改进开发流程。无论软件的高级（未指定）级别如何，都应尽快开始编写单元测试。每当开发人员创建或更改方法时，它都会做一些具体的事情，可以（并且应该）对其进行单元测试。以我的经验，即使更改高级要求也通常不会严重影响这些低级代码块：大多数情况下，代码需要重新排列，而不是丢弃或完全重写。因此，大多数现有的单元测试将保持正常运行。

进行单元测试的一个重要条件是：截止日期不应由管理层预先决定，而应基于开发人员的工作估算（开发人员应在估算中包括编写适当的单元测试所需的时间）。或者，如果最后期限是固定的，则交货范围应可协商。任何数量的（错误）管理都不能改变一个基本事实，即给定数量的开发人员只能在给定的时间内交付一定数量的优质工作。

与此平行，开始讨论澄清和记录需求并将其转变为高级验收测试的最佳方法。这是一个持续不断的细化过程，需要较长的时间，而整个组织要达到更好的稳定状态可能需要花费数年的时间。从您的描述中似乎可以肯定地说一件事：试图通过预先编写大型规范文档来解决不断变化的需求只是行不通。相反，建议采取更敏捷的方法，经常向用户发布软件和演示，并就他们的实际需求进行了很多讨论。用户有权随时更改其关于需求的想法-但是，每次更改都有其成本（时间和金钱）。开发人员可以估算每个变更请求的成本，从而使用户/产品所有者可以做出明智的决定。“当然，此功能更改会很好...但是，如果它延迟了此其他关键功能的发布，并且花费如此之高，那么现在就将其放入待办事项中。”

让用户定义验收测试用例并创建测试数据是一种使它们更多地参与并在用户和开发人员之间建立相互信任的好方法。这迫使双方都专注于具体的，可测量的，可测试的验收标准，并比一般情况更仔细地考虑用例。结果，用户可以在每个发行版上直接查看开发的当前状态，并且开发人员可以获得有关项目状态的更具体，切实的测量反馈。请注意，尽管这需要用户作出更大的承诺，并需要新的操作方法，但这可能很难接受和学习。

我的过渡经验

多年以来，我一直误以为我没有足够的时间为我的代码编写单元测试。当我确实编写测试时，它们是肿的，沉重的东西，这仅鼓励我认为我应该只在知道需要它们时才编写单元测试。

最近，我被鼓励使用“ 测试驱动开发”，我发现它是一个完整的启示。我现在坚信，我没有时间不编写单元测试。

根据我的经验，通过考虑测试进行开发，最终会得到更简洁的界面，更集中的类和模块以及通常更多的SOLID可测试代码。

每当我使用没有单元测试的遗留代码而不得不手动测试某些东西时，我一直在想：“如果此代码已经具有单元测试，这将更快。” 每当我不得不尝试向具有高耦合性的代码中添加单元测试功能时，我总是在想：“如果以非耦合的方式编写，这将变得更加容易”。

比较和对比我支持的两个实验站。一个已经存在了一段时间，并拥有大量的遗留代码，而另一个则相对较新。

在向旧实验室中添加功能时，通常是下到实验室并花费大量时间来研究其所需功能的含义以及如何在不影响任何其他功能的情况下添加该功能的情况。根本没有将代码设置为允许离线测试，因此几乎所有内容都必须在线开发。如果我确实尝试离线开发，那么最终我将得到比合理数量更多的模拟对象。

在较新的实验室中，我通常可以通过以下方式添加功能：在我的办公桌上离线开发它，仅模拟那些立即需要的东西，然后只花很短的时间在实验室中，以解决所有未解决的问题。 -线。

我的建议

看来您的开端很好，每当您要对开发工作流程进行重大更改时，都必须确保每个人都参与制定该决策，并且理想情况下，大多数人都已对此做出了选择。从您的问题来看，您似乎已经正确。如果人们对这个想法不感兴趣，那么它注定会失败或产生不良意愿。

除非您能提出令人信服的业务案例，否则我不建议您为整个系统完全实施单元测试和规范。正如我上面提到的，如果系统设计时没有考虑到测试，那么为它编写自动化测试可能非常困难。

相反，我建议从小处开始，并使用童子军规则：

一定要离开营地的清洁工。

如果在此代码库上实施某些工作时，可以确定测试现有行为并从旧行为过渡到新行为所需的特定测试，那么您既已记录了规范的更改，又开始了针对以下方面的单元测试的实现你的系统。

您不接触的模块不会获得单元测试，但是如果您不接触它们，则可能是因为它们已经在使用中经过了全面测试，不需要更改，或者从未使用过。

您要避免的是浪费开发人员的工作量，编写不必要的测试（YAGNI的测试代码与生产代码* 8'一样好用），再也不会被使用并使人们士气低落认为测试毕竟没有用。

摘要

从小处着手，逐步建立对测试的信任，并在何时何地开发对您的团队最有利的测试中获得业务价值。

首先要做的不是集中在测试上，而是集中在正确的整个过程上。如果您不完全了解应该做的事情，那就没有任何意义！

因此，首先是规格，并记录了不变的规格（嗯，不是立即进行的）。您必须着眼于完成这些工作。我建议一个网站，用户可以在其中上传规格或直接输入规格。您还可以将其链接到错误跟踪器以及项目进度指南。

很有可能，这就是您真正需要的。您可以在内部添加单元测试，并且管理人员永远不需要知道开发人员正在进行单元测试。从某种意义上讲，这就是应该的方式。

您仍然需要进行系统测试，但是也可以链接到项目管理网站，该网站发布后，测试团队（即使这是另一个幸运的轮换开发人员）也可以使用他们曾经使用过的测试对其进行更新。整个事情挂在一起。

老实说，我认为这不会在一夜之间改变，如果您习惯了“口口相传”的规格，那么这场战斗几乎将完全改变这种行为-而您将对此有所抵触。习惯于说“只是做x”的用户（或BA或PM或其他人）现在需要将其全部写下来并不能很好地回应，他们可能会写模糊的规范文档，然后加以澄清口碑更新。因此，请不要进行单元测试，而要着手解决开发生命周期中的大问题。

第一个问题：为了“给开发人员一组测试数据和单元测试”，您必须首先编写那些单元测试，这是开发人员的工作。单元测试也不会取代规范：规范旨在具有比单元测试更高的抽象级别。

第二个问题：似乎您想要最大的单元测试覆盖率。在这种情况下，是的，在需求不断变化的情况下编写测试和代码会花费太多时间和金钱。相反，请确定代码的哪些部分至关重要，然后仅对那些部分进行单元测试。在许多情况下，变化的要求不会影响产品的关键部分。客户（或CEO，或其他任何人）通常会要求将该面板向右移动，或将该标题的颜色从红色更改为绿色：无人问津且不需要大量测试的事情。另一方面，客户绝不会要求将哈希算法从SHA512更改为SHA256或更改您存储会话的方式，而这些部分则需要最多的测试。