45

您如何说服经理让您进行单元测试？

“使用”是指被允许开发，检入源代码控制并随着时间的推移维护单元测试等。

典型的管理异议是：

客户没有为单元测试付费
该项目没有时间进行单元测试
技术债务？什么技术债务？

您知道其他异议吗？你的答案是什么？

提前致谢！

— 路易丝
source

6

关于这个主题，在artofunittesting.com中有一整章。

— StuperUser 2011年

6

不要混用测试和TDD，请！它使人们认为除非进行TDD，否则他们不需要测试！

— P Shved

1

需要说服力的人无法令人信服。考虑您的情况是一个失败的原因。

— Mark Canlas

@Pavel，起初我以为你在挑剔，但是你是对的。我想拥有单元测试期的“许可”。TDD是我自己的事情。

— louisgab 2011年

6

为什么您觉得需要获得许可才能验证您的代码是否按预期工作？

— Jaap，

25

最近，当一个客户加入我们的方法时，我遇到了这个问题，但是更高层的管理者感到开发人员正在花费时间进行测试而不是进行开发，并且对此感到担忧-毕竟，他们有质量检查人员来进行测试！我在这里写了关于如何处理的博客：

http://practicalagility.com/show-them-the-numbers-its-results-that-matter/

总而言之，我将我们的估计工时与项目的实际工时进行了比较，然后将我们的缺陷率与其他团队的缺陷率进行了比较。在我们的案例中，这些数字相比而言是有利的，没有更多的担忧了。

根据此经验得出的结论是：

...说服任何人相信您做某事的方法既实用又务实的最佳方法是做到这一点，并与其他方法进行比较。人们不在乎教条，也不在乎为什么您认为应该是最好的方法。只有向人们展示数字并衡量您的方法的有效性，您才能真正证明您的实践是有效的。

在其他项目中，我们与没有创建单元测试或未进行TDD的客户开发人员一起工作，我们必须维护会破坏它们的测试。但是，将TDD方法出售给那些客户开发人员变得非常容易，只要您可以告诉他们他们在代码中已经破坏了什么，然后他们才知道！

因此，在您的情况下，如有必要，我会秘密执行（也许只有一小段代码可以开始测试经常更改或您负责的代码），但请注意您的数字 -什么是代码努力创建测试？缺陷率是多少？与其他项目/团队成员相比如何？

在我看来，没有人需要为做好自己的工作而征求许可或道歉，并且任何专业开发人员都应尝试在可能和可行的情况下使用自动测试来测试其代码。希望这两种情况都适合您。祝好运！

— Paddyslacker
source

感谢您的回复。我尝试了链接，但它似乎坏了。如果可以的话，我想我会喜欢的。

— 乔J

乔，对这个死链接感到抱歉。我将其重新发布到了我的个人博客上，因此该链接现在应该可以使用了。

— Paddyslacker 2015年

2

这是一个很好的答案，但并不是每个人都可以轻松地将自己在做的事情与其他项目进行比较。我不记得我在哪里读的书，但是对于我所见过的商务人士而言，最令人信服的论据是将单元测试与两次录入记账进行比较。天真的，重复两次是浪费时间。但是，凡是对会计一无所知的人都会认为，只做账面的一面是不可原谅的，不负责任的失职。单元测试是双重记账的发展模拟。

— JimmyJames

@JimmyJames，我同意您不能总是将它与另一个项目进行比较，并且我也同意您关于重复录入簿记的类比。我确实认为，如果您开始在没有测试的现有代码库上使用单元测试，则可以在单元测试所涵盖的部分与未发现的代码之间比较代码库的缺陷率和其他指标，从而可以备份一些实际数据。您的方法也是。

— Paddyslacker

@Paddyslacker我不同意。虽然有点鸡和蛋。如果需要开始编写单元测试的权限，则很难用它们来证明应授予权限的证据。既不是也不是。与真实数据的比较是一个强有力得多的论据。此替代参数较弱，但更易于安装。

— JimmyJames

20

显示投资回报率（ROI）

编写自动化测试需要时间。一旦。运行自动化测试只需花费零时间，因为您可以在运行自动化测试时执行其他操作。

示例：手动测试功能X需要30分钟。为此编写一个自动化测试将花费1个小时。即使没有错误，我们也必须在项目过程中对特征X进行十次测试，因为其相关层和组件已被修改。因此，自动执行功能X的测试将在整个项目生命周期内为我们节省4个小时。

实际上，只有当您遇到一个错误时，自动化测试才能真正得到回报-首先，它们可以及早且廉价地发现错误，从而节省了时间和尴尬。其次，如果您遇到了一个困难的错误，并且要经过很多次代码构建测试才能弄清楚它，那么与手动测试相比，节省的时间就非常快。

企业了解节省时间和金钱。那是卖的方法。

— 史蒂文·A·劳
source

3

同样，一旦部署了应用程序并且有人要求进行更改，查看更改是否对您造成任何破坏就容易得多。

— m4tt1mus 2011年

4

@mattimus：绝对-自动化测试套件可以像年金一样获得回报；它实际上是保险

— Steven A. Lowe

15

如果您已经遇到过他们，并且他们对此表示不满意，但是如果没有他们，您会不满意编写代码……那么就不要再问了。只需写它们，不要签入。

管理层不会计算代码行数，但是他们会看到您的所有签入都具有来自QA（或客户）更高的通过率，并且他们最终会问为什么...然后您就可以像“ BAM！TDD”一样！！”

您不会搞乱项目，流程或源代码……所以我看不出任何负面原因。坦率地说，我看不出为什么它与运行所有手动运行+输入+检查结果测试的时间不同。

— 史蒂文·埃弗斯（Steven Evers）
source

4

+1：您仍然必须进行测试。只是编写单元测试，而不是对如何“完成”测试有所怀疑。

— S.Lott

1

在本地使用它们在共享代码库的团队环境中不能很好地工作，其他人将不断通过更改来破坏您的测试。

— Alb

3

@Alb：那是您不参加管理时要付出的代价-比没有测试要好。

— 史蒂文·埃弗斯

3

太棒了任何测试总比没有测试好。如果由于其他人的更改而导致测试失败，这是一个很好的理由，询问为什么API更改而没有任何通知。

— 美国洛特

“管理不会计算代码行”是非常正确的。感谢您的回答！

— louisgab 2011年

7

1）客户没有为单元测试付费

客户（认为他们）为有效的解决方案付费。根据合同，修复缺陷实际上可能对您的公司有利。如果有足够的锁定，那么请回到为可行的解决方案付费。TDD应该有助于实现这一目标。

2）该项目没有时间进行TDD

TDD不需要花费更长的时间。它应减少多余或多余的代码量，并使代码基于使测试通过的内容。所有测试通过，取决于测试质量和适当性，表示代码已完成。

3）技术债务？什么技术债务？

我得到的印象是，您可能在争先恐后地向现有代码添加测试。最好的时候，这是一场噩梦，并没有带来您可能期望的收益。但是，在修复错误时添加测试应该是可以接受的，并且从长远来看会有所帮助。

我不建议像Snorfus所建议的那样编写测试。从理论上讲听起来不错，但是单元测试可以并且确实会随着时间而改变。随着需求的变化，添加了新功能，需要更新单元测试。如果您是团队成员，则单元测试将过时，因为其他人会添加功能/修复程序。

我要讲的是您提到的具体要点，而不是提出新的要点，因为那里还有余地可以取得进展，也可以理解为什么它被阻塞了。

— 伊恩
source

5

“无论如何我不建议编写测试”-以前我一直担任这个职位。很难自己维护测试。如果负担过重，请放弃测试。至少在您积极地在代码库中工作时才有它们，这应该有助于初始设计/修复，即使不能及时发现回归问题。我已经发现出于设计目的在单元测试中具有巨大的价值，但是当测试未保持在与代码相同的级别时，我发现相当少的回归。

— 史蒂夫·杰克逊

1

谁添加了功能/修复程序但没有更新单元测试，谁都不了解单元测试的概念。

— 山本彰（Akira Yamamoto）

的确，晃是影响TDD或相关流程生存能力的最复杂的问题之一。请记住，我显然是在7年前写的，仍然有很多相关内容。编写（好的，客观的，简洁的）测试很困难。为没有代码的代码库编写测试非常困难。使非技术管理人员看到收益是很难的（除非他们阅读了一篇有关此事的文章，否则您将被“度量”到死亡。即使是什么是单位的概念也很难。我是古典主义者，所以我对单位的想法与模拟人的想法不同（例如，剩下30个字符）

— Ian

4

对于每个面临生产问题的客户，

编写单元测试，并向经理发送电子邮件，说明您已添加单元测试来涵盖该场景。
并告诉他该问题不会在生产中再次发生，因为我们的单元测试在夜间运行，并且通过观察此单元测试失败，我们将在代码投入生产之前就知道了。
告诉他，如果我们在代码投入生产之前已经进行了此单元测试，那么这个生产问题将永远不会发生。

始终如一地做到这一点，很快他就会被说服。经理不喜欢面对生产问题的客户，他会接受单元测试的想法。祝好运。

— java_mouse
source

这很好:-)

— BVengerov '16

您如何说服管理层“投资”单元测试？

显示投资回报率（ROI）