同事不愿使用单元测试“因为要编写更多代码”

一位同事不愿使用单元测试，而是选择快速测试，然后将其传递给用户，如果一切顺利，它会实时发布。毋庸置疑，某些错误确实可以解决。

我提到我们应该考虑使用单元测试-但是一旦意识到必须编写更多代码，她全都反对。这使我无法修改某些内容，并且不确定输出是否相同，尤其是因为她的代码是意大利细面条，因此我会在有机会时尝试对其进行重构。

那么对我来说最好的前进方向是什么？

她不知道单元测试的好处，这就是您需要更改的地方：

• 她的意识。

您必须证明她不仅可以改善她的工作，而且可以改善她的工作。这将是困难的，如果她害怕改变，她可能会尝试着重于发现的每个负面方面。

您可以尝试与她讨论所有好处，并听取她的所有反对意见。等到她说完为止，然后再开始讲自己。

为了做好准备，您应该使用P.SE或Google来解决管理人员或开发人员担心单元测试的所有问题，并编译与同事讨论时将使用的答案。

仅听她的话并提供证明可以改善她的工作，这将对您有很大帮助。您证明自己对她的意见感到担心，并且向她提供了她分析情况并最终改变主意所需的所有数据。

编写单元测试（不要告诉她）

等到事情破裂为止，让她进行两天的手动测试，然后抽出单元测试并在三秒钟内找到错误。

掩护...

自动化手动任务应该吸引任何程序员。

因此，她不是在“编写更多代码”，而是在手动操作上更少。

自动化测试的重点之一是重复性。如果您手动进行快速测试，则完成它的速度可能比编写单元测试的速度快（至少对于单元测试的初学者-拥有单元测试经验的任何人都可以很快地完成测试）。

但是，明天或下周对代码进行小（或大...）更改会怎样？您的同事会在每次更改后高兴地重复一次相同的手动测试，以确保没有损坏吗？还是她更喜欢“编码并祈祷”？

更改的代码越多，单元测试就可以偿还您的初始投资。即使没有真正发现任何错误，测试也不会花很多时间。但是他们也经常这样做-在这一点上，他们变得非常宝贵。一旦有人经历了这种安全感，并且对成功进行单元测试运行的代码充满信心，通常就不会退缩。

如果她很有说服力但不敢冒险进入新领域，请为她提供一对编程课程，以共同编写她的第一个单元测试。选择一个不太难测但足够复杂的课程，值得进行测试。

但是，如果她不相信她，则可能需要继续收集事实。这样的事实可能是

• 您与她编写的代码中的缺陷率
• 根据她的代码编写一组单元测试，并记录发现的错误。

收集一些这样的数据，然后礼貌地向她展示结果。如果这些还不足以说服她，您可能需要讨论问题并与管理层分享您收集的证据。那只是您的不得已的手段，但有时别无选择。

为她的代码中最糟糕的部分编写一个基本的测试范围，然后基于这些测试对其进行分解，然后与管理层联系，证明在连续构建中进行单元测试将提高生产率。当由雇主强制执行而不是由单个开发人员进行传播时，更改变得更加容易。

不知道如何正确地表达这一点，但是：如果您在“有机会的时候”重构她的代码……那么，她可能会认为您参与到“她的业务”中有点不妥当。 ，因此不太可能以开放的心态聆听您的声音。根据我的经验，人们会执着于所做的事情-即使情况不是很理想。

扮演恶魔的拥护者：她有道理。我通常将其表示为：

自动测试解决了很多代码甚至更多代码的问题。

理由：

• 关于故障率和OO度量的相关性的研究，标题结果： “在控制了[类别]的大小之后，我们研究的所有度量均不再与故障倾向性相关”。（该研究讨论了类的大小。这种影响会扩展到代码库的大小吗？可能在我看来。）
• 根据经验，大型项目往往进展缓慢。“在一个新项目中通宵达5K线”与“大型项目每天10线”。这是否表示随着代码库大小的增加而变化的“阻力”？
• 我们始终宣称“没有最好的语言，这取决于问题。” 一项关键要求是以所选语言轻松地对问题实体和操作进行建模。难道这不是建议选择一种语言，其中表达你的问题更复杂的是糟糕的，而不会是再次与代码库的最终尺寸归属关系？

现在，有一些论点很容易对此提出质疑。让我解决我能想到的那些问题：

• 大小与简单：当然，可以使代码更短或更差。但是，这只是比较具有不同简洁性与简单性比率的代码库时的一个问题，因为在讨论中可以假定我们可以以某种方式控制这一因素。

• 单元测试向您施加压力，要求您减少依赖关系，我从经验上同意，减少依赖关系可以减轻代码大小的问题（就两个大小相似的代码库而言，相互依赖性更大的代码库更糟）。但是，在减少生产代码单元之间的依赖性的同时，它在测试和单元本身之间引入了耦合。

TL; DR：我并不认为单元测试是坏的。我问：是否有一个收支平衡点，测试的伤害与代码量有关？

我认为你处境艰难。我曾经在一个团队中工作，他们不会编写单元测试，或更糟糕的是，可怕的不可维护的单元测试。但是每个人都知道单元测试很好。

因此，要使团队的单元测试套件具有良好的质量，是一条漫长的艰难道路。始终关注可以改进的地方，交流思想，分享经验。

另一方面，您所拥有的开发人员甚至没有意识到其好处。然后还编码意大利面条代码。我猜在这种特殊情况下，最重要的原因之一是编写良好的单元测试会导致松耦合设计。因此，从长远来看，让她编写测试可以有望改善“真实”代码。

但是我认为最终是团队决定（我不知道你在团队中有多少？）。如果团队可以达成共识，那就是应该有一个完善的单元测试套件，那么每个人都必须遵循，分享经验，并让您的团队共同成长。

但是，如果团队无法就您应该编写单元测试达成共识，那么我建议您找一个不同的开发团队与之合作；）

她是老板吗？

如果是这样的话，除非您能说服她基本上遵循“一分预防胜过一磅的治疗”的好处，否则您将陷于困境。虫子穿过。TDD通过建立一致的输出来帮助减轻这种情况。

她不是老板吗？

您工作的编码标准是什么？为什么允许她散发出意大利面条代码？向老板提出一个业务案例，说“如果我们在TDD上花更多的时间，我们将在bug上花很多时间”。说服可以通过业务案例实施变更的人。

记录下TDD可以节省时间和$$ MONEY $$的案例。

此错误本身。它会在上线之前被捕获。花费2个小时的预防将为我们节省10个小时的治愈时间。它发生在这里，这里和这里。那10个小时的工作本可以为公司节省30个工时。这么多钱。

这使我可以修改某些东西

为什么？

他们制造了问题。他们应该解决它。

哪个经理允许这种情况发生？为什么现在别人的错误代码成为您的问题？

您有一位同事和一位经理都在实现这一目标。通过清理他们的混乱状况，您将成为积极主动的参与者。

如果他们不感到质量低劣的痛苦，什么都不会改变。

她是完全正确的，单元测试是“更多代码”。

但是，只需编写更多代码即可确定程序的工作方式（应一遍又一遍）。这不是浪费时间。它和核心组件一样，是系统的一部分。

向她挑战：

1. 如果不熟悉该代码的人进行更改，会发生什么情况。
2. 如果一个没有经验的人改变了东西会发生什么。
3. 维护系统的成本不会以创建所需的时间来衡量。这是一个长期的主张。考虑一下总拥有成本。
4. 她的估计（如果在开始编码之前需要这样做）应该包括编写单元测试的要求。商务人员不会创建直接需要单元测试的需求，但确实有对质量的隐含需求，并且要求将来的更改不要被错误所困扰，或者要求同一位程序员更改其源代码。

说到目前正在生产代码中，然后是单元测试而不是TDD，这似乎不适合我目前的位置（我已经在某些项目上进行过TDD，但将其视为另一种工具袋子，不是银弹）...

可能很难卖。我仍然无法出售我的同事进行单元测试。我知道我在单元测试代码中比在生产代码中容易犯更多的错误。因此，不得不花费大量时间修复单元测试代码有点令人沮丧。但是，修改代码后，这是很好的保证。自动测试边缘条件的好方法。

向她展示自己创建单元测试对单元测试有多大帮助。

正如圣弗朗西斯（St. Francis）曾经说过的那样：“始终坚持。在必要时，使用文字”

如果她发现您的代码正在使用单元测试，并且您能够使用单元测试更快地解决错误，则可能会改变主意。但是，可能不会。

不管结果如何，她都不会把你看作是你不愿意做的事情。那就是您必须改变的感觉，即您没有以身作则。