当同事因为我的提交包含单元测试而拒绝我的提交时,我应该怎么做?

你刚刚遇到了最困难的软件问题:人。当我在没有更多背景的情况下犹豫不决地猜测你的老板时(例如,这真的是完整的测试图吗?),完全拒绝您的代码仅仅是因为您包含了单元测试,充其量是一个有问题的实践。

最明智的方法是与此人进行一对一的交谈,以便了解他的立场。 你说你的老板很难改变,但通常情况下,人们并不是那么黑和白。例如,考虑到您在项目中的新状态,他可能认为您提交的代码量有风险,不理解您的单元测试使您能够编写更多的代码,因为您可以对它有更高的信心。所以我会让他从怀疑中受益,并且先心心相印。

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

• 你对单元测试有什么看法?它们如何融入我们的整体测试策略?

• 你对我提交的单元测试有什么意见?它们在某种程度上是不足的还是缺乏的?你对单元测试本身还满意吗,但是你更希望我的代码组织得与众不同?

• 为什么我们所有的代码都要在功能级别上测试?

• 所有的单元测试对我们的项目是坏的还是不合适的?

• 当这些条件在更高的接口级别上更复杂时,您计划如何发现与方法的特定输入相关的问题?

• 如果您对签入单元测试有特定的反对意见,是否反对在本地使用单元测试以便我至少可以验证自己的代码?

如果你觉得你现在理解了他的立场,并且你想用这种方式来编写软件是站不住脚的,那么你有一个不同的问题要问自己:你是否喜欢这份工作,即使在专业上有问题的实践中仍然留在团队中,或者是时候开始寻找其他的方法了?E?

相反,如果你觉得你现在明白了为什么会有规则,并且你认为从项目的整体背景来看这是明智的,那么huzzah!你通过专业地处理自己来避免潜在的危机,你可以和你的新团队呆在一起,你可以回到有趣的部分:软件开发。

编辑: 我真的不同意这个问题中的一些帖子,告诉OP让自己适应这个团队。只有当团队接受实践时,实践的标准化才是好的。我们应该鼓励他去理解,而不是让操作人员把事情搞得一团糟。 为什么? 这条规则已经制定好了,因此他可以根据自己的优点来评估它是否有意义。

经理也有一些解释,以便他能帮助运营商以自己的方式看待事情。当然,不是每个人都会一直同意经理的观点。我领导过项目或团队,做出了一些不能让每个人都满意的决定,但我总是试图先从每个人的意见中做出决定,这样我才能做出最好的决定。在我看来,在不考虑对团队的影响和忽略其他建议的情况下,执行菲亚特管理层的一套“标准”会让你 坏的 经理,不太好。

在开发团队中,最重要的是坚持标准,即使你不同意标准。如果每个人都做自己的事,那么有标准是没有意义的。

你可以保留单元测试来满足你的个人满意度/信心。也许有一天你可以证明你的方法已经阻止了一个bug的再次出现,或者以某种方式让团队受益,然后你的观点可能会更容易被接受。

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

免责声明:我在适当的时候使用单元测试,任何为我工作的人也会被鼓励使用。

将单元测试存储在并行版本控制中,并且只将代码提交给中央系统。他会在没有单元测试的情况下检查你的代码,你仍然可以从中受益…

另外,我建议您使用一个分布式版本控制,您可以玩一个新的有趣的玩具,当您的另一个同事想要尝试时,他可以轻松地接受和扩展您的测试套件。

编辑 澄清以下意见:

我建议他为单元测试建立一个本地源代码库。代码本身仍将与托管存储库同步(通过正常的提交过程,只是不与代码一起提交测试)。

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

他的想法是,使用单元测试,他可以希望自己的错误率低于其他人。当他和他的技术主管争论这类事情时,这会有帮助。 只要他按时完成分配的工作,我不明白他为什么不能按他认为合适的方式工作。

对不起,你得适应这个队。你必须经常和他们谈论单元测试,你不能在一天之内说服他们。

我的主管对oop一无所知,他还在用c_编程,现在说服他使用构造器,也许几个月后他会用私有字段/方法代替静态方法。

适应自己。

几分钟后你就会得到一些对你最有利的答案。将此线程显示给抵制代码的人。:)

单元测试有成本,而不仅仅是收益。从 http://www.joelonsoftware.com/items/2009/09/23.html :

扎温斯基没有做很多单元测试。 他们原则上听起来很棒。鉴于 悠闲的发展步伐 当然还有路要走。但是什么时候 你在看,我们得走了 从零到六周内完成,嗯, 我不能那样做除非我切了点东西 出来。我要做的是 不是绝对的 关键的。单元测试不是 关键的。如果没有单元测试 顾客不会抱怨 那个。

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

我现在的主要问题是 单元测试是指当我改变设计时 得到一堆失败的测试。这个 意味着我要么写得少一点 测试或减少大型设计 变化。两者都是坏事。

我是个懒散的混蛋,写的单元测试不够,但是当我的人努力写单元测试的时候,我没有傻到拒绝单元测试。你可以试着在愚蠢的管理范围内工作,但除非有希望这家伙很快就会从现场消失,我建议你找另一个团队。

让你的组长读一下 this paper (pdf),(您可以在 this blog post )看看他是否改变主意。

现在,一项研究并没有证明什么,但是有一段非常有趣的摘要:

我们发现第一次考试的学生 Average写了更多的测试,反过来, 写更多测试的学生倾向于 才能更有效率。我们也 观察到最低质量 随着 程序员测试,独立于 采用发展战略。

换句话说,更好的测试,更好的代码。时期。(这与我的经验,以及与我合作过的无数其他开发人员的经验相符。)

如果你不能让这个人改变主意,那就去别处找工作吧——你已经在一个失败的团队里结束了,那里的负责人对学习新东西毫无防备。不好的。

编辑: 有几十项研究显示了tdd的有效性。尝试 here 和 here 更多。

如果团队没有维护单元测试套件的经验,那么他们就有问题,但是如果他在公司比你更重要,你就很难解决问题。

我在一次大学软件质量讲座中得到的一个好建议是:

如果你进入了一个团队/公司,他们真的不知道如何制作软件。试着帮助他们提高(承认没有一个好方法,但不尝试不是方法)。提出好的论据(比如:我的代码错误更少,编写时间也一样?)。如果你不能改变公司/团队:不要留下来,开始找一份新工作,在这家公司或另一家公司。

在我看来,他拒绝签入包含执行单元测试代码的源代码,对吧?

解决这个问题的简单方法是不要尝试签入单元测试代码。您仍然可以编写它并执行单元测试,但要将其分开。如果您想控制它的修订,请为单元测试保留单独的存储库。

这就是我20多岁的职业生涯中的大部分时间。我想我只做过一个正式跟踪单元测试的程序,就像你以前的团队那样。

继续编写这些测试,但不要编写琐碎的测试。也许通过一个小小的测试,你认为你可以教育别人,但他们可能认为这是浪费时间的证明。尝试通过编写一个测试来修复错误,以重现问题,并就您对团队所做的事情做一个演示。试着不要把单元测试当作一种新的信条来推销,但是试着解释为什么这是你工作的方式。先把精力花在说服其他团队成员上。

在某个时候,他们会注意到你可以对你的代码的实现做很大的改变而不需要回归。

将单元测试重命名为“en camera functional tests”。

编辑: 更实际地说,如果您不能克服human元素,您可以在一个小型的、私有的、并行的存储库中维护您的单元测试。在开发或维护时将它们解包,运行它们,更新它们,然后将它们保存到下次。

有趣的是代码被拒绝了 因为 单元测试。如果你把它们排除在你提交的代码之外,它会被接受吗?如果是这样的话,您只需继续进行单元测试,并不断地生成通过这些单元测试的生产代码。如果您的测试是好的,那么它们只会改进您提交的生产代码。编写单元测试的“开销”并没有那么多——当然,与查找下游的bug相比。

也就是说,你不能走进一个新的群体,期望一夜之间改变这个群体的文化——这种情况通常不会发生。最好保持良好的实践并提交通过测试的代码。及时,你的同事可能会来,或者规则可能会改变。人们不愿意改变,直到他们看到好处。

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

我将提出一个不那么戏剧化的约翰·费米内拉的答案。

和有问题的人谈谈,但不要大吵大闹。当然不要说“你为什么不喜欢我做一些能让我的代码更好的事情”,这是对他的知识的挑战,而且考虑到许多开发人员对隐含的批评相当敏感,他可能会告诉你迷失方向。

相反,我会首先澄清“你只是因为我包含了这个测试代码而没有通过评审吗?” 然后说“当我编写测试时,我发现我的工作效率更高,我签入测试的问题是什么”

另一方面,单元测试可能被评审者拒绝的原因可能是:

• 很可能,规则适用于项目中的所有代码
• 这意味着单元测试意味着要审查更多的代码
• 单元测试不能以满足一般评审/编码标准的方式编写

特别是在C++中,我设想您的测试与主应用程序代码混合,因为在项目中已经没有单元测试设置。在这种情况下,它可能会使代码更难遵循。

这并不能真正解决你的问题,但是你没有提到你是否得到了代码覆盖率。

功能测试加上代码覆盖率可以有效地演示代码的正确性,并且在您的管理者进入这个行列时可能很流行。

主要的问题是,这是一个很大的努力,并不是很实际时,你的代码仍然在流动。