当同事因为包含单元测试而拒绝我的提交时，我该怎么办？

Question

我在同一家公司从一个团队搬到另一个团队。在旧团队（硬核c ++）中，我们进行了大量的单元测试。在我的新团队（也是c ++）中，他们进行功能测试。在审查期间，由于单元测试，他们拒绝我的代码。大多数团队都有兴趣学习新的东西，但不是那个VIP的人，并且有遗留的开发者方法。他必须在提交前接受代码。他抵制这种变化。建议？

//更新：我将在这个主题中告知我的任务发生了什么，但请理解它是一家大公司，需要时间。只是为了澄清，我做的测试很好，它总是在其他团队中工作。我不是新手。我不时需要制动依赖关系导致代码明显废话。在C ++中，你有时必须这样做。这可能仅仅因为测试而引入了prod代码的变化。我认为进行单元测试证明了这种简单的改变。拥有它比拥有它更好。

// update2：感谢你提供了很多好的建议，显然这里没有灵丹妙药:(大部分球队都相信，但是2位高级（15y +）开发者仍然反对。我会简短地谈谈剩下的我的团队会支持我，所以我希望那些家伙会同意:)放松一下我开始学习红宝石:)）

Answer 1

你刚刚遇到了最困难的软件问题：人。虽然我在没有更多背景的情况下对你的老板进行二次猜测犹豫不决（例如，这真的是完整的测试图片吗？），完全拒绝你的代码仅仅是因为你包括单元测试充其量是一个值得怀疑的做法。

最明智的路线是与这个人进行一对一的聊天，以便你了解他的位置。你形容你的老板对改变有抵抗力，但通常人们不是那么黑和白色。例如，考虑到您在项目中的新状态，他可能会将您提交的代码量视为风险，而不是了解您的单元测试可以让您编写更多代码，因为您可以对其有更高的信心。所以我会给他怀疑的好处，并且首先要有心连心。

以下是您在谈话中要问的一些问题：

• 您对单元测试有何看法？它们如何适合我们的整体测试策略？

• 您提交的单元测试有什么问题？他们是否缺乏或缺乏某种方式？您是否对单元测试本身没问题，但是我希望我的代码组织方式不同？

• 为什么我们的所有代码都应在功能级别进行测试？

• 我们的项目是否所有单元测试都不合适或不合适？

• 如果在较高的接口级别复制这些条件更复杂，您打算如何发现与方法的特定输入相关的问题？

• 如果您对签入的单元测试有特定的异议，是否有人反对在本地使用单元测试，以便至少可以验证我自己的代码？

如果你觉得你现在理解他的立场并且你想要编写软件的方式是站不住脚的，你会有一个不同的问题要问自己：尽管存在专业问题，你是否仍然享受足够的工作以留在团队中？实践，还是时候开始寻找其他地方了？

相反，如果你觉得你现在明白为什么规则在那里，你认为根据项目的整体背景是明智的，那么huzzah！你通过专业的处理来避免潜在的危机，你可以留在你的新团队中，然后你可以回到有趣的部分：软件开发。

---

编辑：我真的不同意这个问题中的一些帖子，告诉OP让自己适应团队。当团队购买实践时，实践的标准化才是好的。我们应该鼓励他理解为什么规则已经到位，而不是告诉操作组将其搞砸并排成一线，这样他就可以根据自己的优点来评估它是否合理。 / p>

经理也有一些解释，他可以帮助OP看他的方式。当然，并非所有人都会一直与经理们达成一致。我领导了项目或团队，并且做出了一些不能让所有人满意的决策，但我总是先尝试用每个人的意见来做出这些决定，这样我才能做出最好的决定。在我看来，通过管理命令执行一套“标准”而不考虑对团队的影响而忽略其他建议会使你成为糟糕的经理，而不是一个好的经理。

Answer 2

开发团队中最重要的事情是坚持标准，即使您不同意标准。如果每个人都做自己的事情，那么制定标准毫无意义。

您可以保持单元测试，以满足您的个人满意度/信心。也许有一天你可以证明你的方法已经停止了以某种方式重新组织或使团队受益的错误，然后可能更容易让你的观点得到满足。

有一天，你会成为制定标准的人，然后有些人会不同意你。然后你可以告诉他们这个故事。

免责声明：我会在适当的时候使用单元测试，并鼓励任何为我工作的人。

Answer 3

将单元测试存储在并行版本控件中，并仅将代码提交到中央系统。他将在没有单元测试的情况下审核您的代码，您仍然可以从中受益......

另外，我建议使用分布式版本控制之一，你可以玩一个有趣的新玩具，当你的其他同事想要尝试时，他可以轻松地拥抱和扩展你的测试套件。 / p>

修改 澄清以下评论：

我建议他为他的单元测试设置一个本地源代码库。代码本身仍将与托管存储库同步（通过正常的提交过程，只是不提交测试和代码）。

他还可以保留他认为在他的硬盘上有用的单元测试，它不会改变任何东西，就像我所知道的任何开发人员有各种用途的“工具”文件一样。

这个想法是，通过单元测试，他可以希望他的错误率低于其他人。在与他的技术主管争论这种事情时，它可以提供帮助。 只要他按时完成指定工作，我就不明白为什么他不能按照自己认为合适的方式工作。

Answer 4

在几分钟内你应该得到一些对你有利的答案。向正在抵制代码的人显示此主题。 ：）

Answer 5

我很抱歉，但你必须让自己适应团队。你不得不经常谈论单元测试，你不可能在一天内说服他们。

我的主管对oop一无所知，他仍然在用c＃编程，现在说服他使用构造函数，也许在几个月内他会用私有字段/方法代替静态方法。

适应自己。

Answer 6

单元测试有成本，而不仅仅是好处。来自http://www.joelonsoftware.com/items/2009/09/23.html：

  

Zawinski没有进行过多次单元测试。   他们“原则上听起来很棒。特定   这是一个悠闲的发展步伐   肯定是要走的路。但当   你在看，'我们得走了   从零到六周完成，'好吧，   除非我剪掉一些东西，否则我不能这样做   出。而我要删除的是   那些不是绝对的东西   危急。单元测试不是   危急。如果没有单元测试的话   顾客不会抱怨   该“。

来自：http://www.codinghorror.com/blog/2005/04/good-test-bad-test.html

  

目前我的主要问题是   单元测试是我改变设计的时候   得到一堆失败的测试。这个   意味着我要么少写   测试或减少大型设计   变化。这两件事都很糟糕。

Answer 7

我是一个懒惰的混蛋，他不会在任何接近单元测试的地方写字，但是当我的家伙们努力写单元测试时，我不会愚蠢地拒绝单元测试。你可以尝试在愚蠢的管理范围内工作，但除非有希望这个家伙很快就会从现场消失，我建议你找另一个团队。

Answer 8

让你的团队领导阅读this paper（pdf），（你可以在this blog post中找到整齐消化的内容），看看他是否改变主意。

现在，一项研究没有证明什么，但有一个非常有趣的外卖段落：

  

我们发现测试优先的学生   平均写了更多的测试，反过来，   写更多考试的学生倾向于   提高工作效率。我们也   观察到最低质量   随着数量的增加而线性增加   程序员测试，独立于   采用的发展战略。

换句话说，更好的测试，更好的代码。期。 （这与我的经验和我与之合作的无数​​其他开发人员的经验相符。）

如果你不能让这个人改变主意，那么在其他地方找工作 - 你最终会遇到一个失败者队伍，那些负责人不会学习新东西。不好。

编辑：有数十项研究显示TDD的有效性。请尝试here和here了解更多信息。

Answer 9

如果团队没有维护单位测试套件的经验，那么他们就会遇到问题，但如果他在公司中比你更重要，那么你几乎无法解决问题。

Answer 10

重命名单元测试“和相机功能测试”。

编辑：更实际的是，如果您无法克服人为因素，您可以将您的单元测试维护在一个小型的私有并行存储库中。在开发或维护，运行它们，更新它们，然后将它们放到下一次之前解压缩它们。

Answer 11

继续编写这些测试，但要避免编写琐碎的测试。也许通过一个微不足道的测试，你认为你可以教育别人，但他们可能会将其视为浪费时间的证明。尝试通过编写测试来重现问题来修复错误，并做一个关于你对团队做了什么的演示。尽量不要将单元测试作为新宗教出售，但要试着解释为什么这是你工作的方式。尽最大努力说服其他团队成员。

在某些时候，他们会注意到您可以对代码的实现进行重大更改而不会退步。

Answer 12

我在大学关于软件质量的讲座中得到的一个好建议：

如果你进入一个他们真的不知道如何制作软件的团队/公司。尽量帮助他们改进（接受没有一个好方法，但不是尝试不是方式）。提出好的论据（例如：我的代码有更少的错误，需要花费相同的时间来编写？）。如果你不能改变公司/团队：不要留下来，开始寻找新的工作，与这家公司或其他公司。

Answer 13

听起来我拒绝检查包含执行单元测试的代码的来源，对吗？

简单的解决方案是不要尝试检查单元测试代码。您仍然可以编写它并执行单元测试，但要将它分开。如果您希望对其进行版本控制，请为您的单元测试保留自己独立的存储库。

这就是我20多年职业生涯中的大部分时间。我想我只参与了一个正式跟踪单元测试的程序，就像你的旧组一样。

Answer 14

这并没有真正解决您的问题，但您没有提及您是否获得了代码覆盖率。

功能测试和代码覆盖可以有效地证明代码的正确性，并且当你的经理上升时可能很受欢迎。

主要的问题是当你的代码仍在不断变化时，它需要付出很多努力而且不太实用。

Answer 15

另一方面，审稿人可能会拒绝单元测试的原因：

• 可能，规则适用于项目中的所有代码
• 这意味着单元测试意味着要审核更多代码
• 单元测试不得以符合一般审核/编码标准的方式编写

特别是在C ++中，我认为您的测试与主应用程序代码混合在一起，因为项目中不存在单元测试设置。在这种情况下，它可能会使代码更难以遵循。

Answer 16

我打算提出一个不那么引人注目的John Feminella的答案。

与相关人士交谈，但不要为此大声唱歌。当然不要说“为什么你不喜欢我做一些让我的代码变得更好的东西”，这对他的知识提出了挑战，并且鉴于许多开发人员对隐含的批评非常敏感，他可能会告诉你迷路。

相反，我首先澄清“你是否只是因为我包含了这个测试代码而未通过审核？” 然后说“我在编写测试时发现我的工作效率更高，我在测试中检查的问题是什么”

Answer 17

有趣的是，代码被拒绝因为的单元测试。如果你把它们从你提交接受的代码中删除了，它会被接受吗？如果是这种情况，您只需继续进行单元测试并继续生成通过这些单元测试的生产代码。如果你的测试是好的，它们只会改进你输入的生产代码。编写单元测试的“开销”并不是那么多 - 当然与下游的bug有关。

那就是说，你不能走进一个新的团体，并期望一夜之间改变团队的文化 - 这通常不会发生。最好是跟上你的良好实践并提交通过测试的代码。随着时间的推移，你的同事可能会到来或规则可能会改变。在看到好处之前，人们不愿意改变。

如果您的代码不符合该小组设定的其他标准，您当然需要解决这个问题。