单元和集成测试：如何成为反射

我们团队中的所有程序员都熟悉单元测试和集成测试。我们都与之合作。我们都对其进行了书面测试。我们中有些人甚至对他/她自己的代码感到更加信任。

但是，由于某种原因，编写单元/集成测试尚未成为团队任何成员的反思。当不与实际代码同时编写单元测试时，我们所有人实际上都不会感到难过。结果，我们的代码库大部分没有被单元测试发现，并且项目未经生产就进入生产。

当然，这样做的问题是，一旦您的项目投入生产并且已经正常运行，就几乎不可能获得时间和/或预算来添加单元/集成测试。

我的团队和成员自己已经熟悉了单元测试的值（1，2），但它似乎并没有帮助将单元测试到我们的工作流程自然不会。根据我的经验，强制执行单元测试和/或目标覆盖范围只会导致质量测试不佳，并且会降低团队成员的速度，这仅仅是因为没有自发产生这些测试的动力。同样，一旦压力减轻，就不再编写单元测试。

我的问题是：您是否尝试过任何方法来帮助团队内部建立动力/动力，导致人们自然地希望创建和维护这些测试？

当不与实际代码同时编写单元测试时，我们所有人实际上都不会感到难过。

这是您需要解决的问题。您的团队的文化需要改变，以便在sprint期间（或您使用的任何时间单位）不编写测试就变得与硬编码值一样多。其中大部分涉及同伴压力。没有人真的希望被视为不合标准。

自己做测试。当你不做时，明显地自责。指出如果“良好”的程序员编写单元测试，将会在哪里捕获该错误。没有人想成为坏人。确保这种不良行为是不良的，并且人们会跟随。

让整个团队真正想要同一件事可能非常困难。通常情况下，仅仅看到某件事的价值本身不足以鼓励人们改变根深蒂固的行为。即使是那些珍视更改并特别想要更改的人，有时也可能负责下意识地与之抗争。

问题实际上是个人动机之一，而不是团队动机。有时候，是由于您最终理解了某些内容，或者是由于某些新工具或其他主观性的东西使您变得一清二楚，这使普通程序员投入了一切并完全改变了过程。您的工作（如果您选择除此以外）是查看您或团队是否有办法找出哪些事情将使每个团队成员的头脑清晰。

对我个人而言，它只是在DotNet中发现了BDD的StoryQ框架，这使得它太容易被忽视，并使我完全摆脱了测试优先与测试同时的“障碍”。后来，当我找到Visual Studio的NCrunch时，我的选择得到了重申。有时，成功的一半不是卖主意，而是简单地降低了彻底改变习惯所需的精力……即使这样，也可能需要花费一些时间和精力。但是，这些相同的个人触发因素还不足以影响当时我的同事的方法，他们的同事仍在同时或什至在实现代码之后编写许多测试代码。

有时，由于固有的恐惧感，不信任感或令人厌恶的观点，人们不愿意改变做事的方式，即使学习改变的理由是正确的，但他们还是不愿意改变学习方式。如果您的整个测试平台都以特定的方式工作，那么很难证明改变工作方式以及潜在地改变工具的合理性，尤其是当新旧测试在整个生命周期中需要继续共存时，尤其如此。项目-您当然不需要重写您曾经创建的每个测试。奇怪的是，有时人们会觉得这是采用新测试方法的唯一方法，这本身就使那些人难以更好地接受明智的改变。

确实，某件事变得反身的唯一方法是强迫自己反复进行，直到您不再注意到自己需要过多地专注于如何做。有时，在团队中做到这一点的唯一方法是制定可能有点过分苛刻的策略，进行结对编程和代码审查，以及任何其他可以帮助团队成员相互支持并从字面上迫使更改的方法在行为发生。但是，要使这种策略真正成功，它仍然需要每个团队成员坚定而诚实的承诺，以接受必要的措施，并参与该过程……以及所有参与者的耐心等待。

当不与实际代码同时编写单元测试时，我们没人真正感到难过

不知道“同时”是什么意思，但是在实际代码之前编写它们又如何呢？

从心理学角度很容易理解，为什么任何人都不想在编写代码后费心编写单元测试。到那时，代码已经可以工作了，那么为什么我们还要进行测试呢？某种懒惰会自动发生，因为它很乏味，看似毫无用处并且不编写测试似乎并不危险。结果，我不知道有很多团队会长期使用“事后测试”方法。

以我的经验，测试优先（TDD风格）是您很快就会上瘾的东西，因为它至少具有2种直接的，切实的，释放内啡肽的好处：

• 它可以帮助您与具体的可执行要求面对面地设计代码，并在重构时使设计变得越来越好，这比仅仅仔细检查已经起作用的东西更加有目的性和可取性。

• TDD周期频繁出现“绿色竖线”时刻，您可以在其中享受立竿见影的成功体验。它不断使您的思想满意，并准备好实施下一个功能。

因此，当他们没有编写测试时，我不会试图让您的团队感到难过。相反，我会尽力使他们感觉良好。TDD是执行此操作的一种方法。

首先，您需要确保编写测试并轻松进行测试，在当前项目中设置框架，并使该设置过程易于包含在以后的项目中

这样，当程序员想要对一个新功能进行单元测试时，他尝试调试就不必跳过十几个箍圈就可以使测试正常运行

做某事越笨拙，就越不可能养成习惯

我所做的一件成功的事情是在促使文化改变方面取得了一些成功，那就是开设一个每周一次的“单元测试策划”研讨会。这样做的官方目的是帮助保持单元测试套件的快速运行和最新状态，但是在我看来，更重要的目的是给人们一种低压力的介入，提问和练习测试的方式。 。您愿意花一个小时或每周专门用于测试的事实这一事实也发出了这样的信息：这很重要。

我认为您会通过这种方式在文化上有所改变，并且开始消除“反身”执行此操作的障碍，就像您所说的那样。人们在逆境的最初征兆中会倾向于恢复旧习惯-召开这样的会议不会一that而就，但我认为这将引发文化变革并消除因并非真正造成的障碍知道你在做什么。

拥有一群所有人都自然想做某事的程序员是一种乌托邦式的工作（特别是在谈论大型团队时）。

单元和集成测试是标准的事情。您为工作流程创建了一个标准，团队中的每个成员都应遵守它。这些标准应在质量检查专业人员的帮助下制定，因为他们对此更加了解。程序员应遵守标准。您可以做的是使标准清晰，易于理解和遵循。

这不是对您自己的代码的信任和使用的欲望，而是关于需要每个人都使用的编码和测试标准以创造美好的事物，任何程序员都应该理解这一点。

当您从一开始就使人们遵循标准时，它就会成为一种反射并且会被遵循。将没有单元测试的任何代码都不能放入代码库定为一条规则，这将使人们相信他们必须这样做。对于项目存储库，甚至还有更多的限制性规则。例如，公司在实际编码单元之前（在制定模块规范时）进行单元测试，这是一种非常好的方法。如果程序员将代码放入项目/代码库中，则代码将在测试模块中运行，并且如果单元测试未通过，则它们将重新工作。

如果目前很难添加标准和规则，至少要考虑在将来的项目中添加它们。