你如何说服别人编写单元测试? [英] How do you persuade others to write unit tests?

问题描述

我已经被测试感染了很长时间，但似乎与我一起工作的大多数开发人员要么从未尝试过，要么出于某种原因而放弃它，通常的论点是它增加了开发或他们不需要打扰.

I've been test-infected for a long time now, but it would seem the majority of developers I work with either have never tried it or dismiss it for one reason or another, with arguments typically being that it adds overhead to development or they don't need to bother.

最让我烦恼的是，当我对他们的代码进行更改时，我很难对其进行测试，因为我必须应用重构以使其可测试，有时最终不得不这样做 大量工作只是为了测试我将要编写的代码.

What bothers me most about this is that when I come along to make changes to their code, I have a hard time getting it under test as I have to apply refactorings to make it testable and sometimes end up having to do a lot of work just so that I can test the code I'm about to write.

我想知道的是，您会使用什么论据来说服其他开发人员开始编写单元测试?我介绍给它的大多数开发人员都很好地接受了它，看到了它的好处并继续使用它.这似乎总是优秀的开发人员，他们已经对提高代码质量感兴趣，因此可以看到单元测试是如何做到这一点的.

What I want to know is, what arguments would you use to persuade other developers to start writing unit tests? Most developers I've introduced to it take to it quite well, see the benefits and continue to use it. This always seems to be the good developers though, who are already interested in improving the quality of their code and hence can see how unit testing does this.

如何说服其他杂七杂八的船员?我不是在寻找测试好处的列表，因为我已经知道这些是什么，而是您已经使用或将使用哪些技术来让其他人参与进来.关于如何说服管理层发挥积极作用的技巧也值得赞赏

How do persuade the rest of the motley crew? I'm not looking for a list of testing benefits as I already know what these are, but what techniques you have used or would use to get other people on board. Tips on how to persuade management to take an active role are appreciated as well

推荐答案

我想这个问题不止一个方面.我发现实际上说服开发人员开始使用测试并不难，因为使用测试的优势列表通常不言而喻.话虽如此，但实际开始是一个很大的障碍，我发现学习曲线通常有点陡峭 - 特别是对于新手编码员.将测试框架、TDD 测试优先的心态和模拟框架扔给那些对 C#、.Net 或一般编程都不熟悉的人，可能太难处理了.

There's more than one side to that question, I guess. I find that actually convincing developers to starting using tests is not that hard, because the list of advantages of using testing often speaks for itself. When that said, it is quite a barrier to actually get going and I find that the learning curve often is a bit steep – especially for novice coders. Throwing testing frameworks, TDD test-first mentality, and mocking framework at someone who's not yet comfortable with neither C#, .Net or programming in general, could be just too much to handle.

我是一名顾问，因此我经常不得不解决在组织中实施 TDD 的问题.幸运的是，当公司雇用我时，通常是因为我在某些领域的专业知识，因此在引起人们的注意方面，我可能有一点优势.或者可能只是作为局外人的我更容易进入一个新团队并说嗨！我已经在其他项目中尝试过 TDD，我知道它有效！"或者是我的说服力/固执?:) 无论哪种方式，我通常都觉得说服开发人员开始编写测试并不难.不过我觉得很难的是教他们如何编写好的单元测试.正如您在问题中指出的那样；坚持走正道.

I work as a consultant and therefore I often have to address the problem of implementing TDD in an organization. Luckily enough, when companies hire me it is often because of my expertise in certain areas, and therefore I might have a little advantage when it comes to getting people’s attention. Or maybe it's just that it's a bit easier to for me as an outsider to come in to a new team and say "Hi! I've tried TDD on other projects and I know that it works!" Or maybe it's my persuasiveness/stubbornness? :) Either way, I often don't find it very hard to convince devs to start writing tests. What I find hard though, is to teach them how to write good unit tests. And as you point out in your question; to stay on the righteous path.

但我发现了一种我认为在教授单元测试时非常有效的方法.我已经在这里写了博客，但本质是坐下来做一些结对编程.在进行结对编程时，我首先开始编写单元测试.通过这种方式，我向他们展示了测试框架是如何工作的，我如何构建测试以及经常使用一些模拟.单元测试应该很简单，所以总的来说，即使对于初级开发人员来说，测试也应该相当容易理解.最难解释的部分通常是模拟，但使用易于阅读的模拟框架，如 Moq 有很大帮助.然后在编写测试(并且没有任何编译或通过)时，我将键盘交给我的编码员，以便他(她)可以实现该功能.我只是告诉她/他；让它变绿！"然后我们继续下一个测试；我编写测试，我旁边的soon-to-be-test-infected-dev"编写功能.

But I have found one method that I think works pretty well when it comes to teaching unit testing. I've blogged about it here, but the essence is to sit down and do some pair-programming. And doing the pair programming I start out writing the unit test first. This way I show them a bit how the testing framework work, how I structure the tests and often some use of mocking. Unit tests should be simple, so all in all the test should be fairly easy to understand even for junior devs. The worst part to explain is often the mocking, but using easy-to-read mocking frameworks like Moq helps a lot. Then when the test is written (and nothing compiles or passes) I hand over the keyboard to my fellow coder so that (s)he can implement the functionality. I simply tell her/him; "Make it go green!" Then we move on to the next test; I write the test, the 'soon-to-be-test-infected-dev' next to me writes the functionality.

现在，重要的是要了解此时您正在教授的开发人员可能还不相信这是正确的编码方式.大多数开发人员似乎看到(绿灯)的一点是，当测试由于某些代码更改而失败时，他们从未想过会破坏任何功能.当涵盖该功能的测试失败时，您的团队中就有了一个忠实的 TDD'er.或者这至少是我的经验，但一如既往；你的里程会有所不同:)

Now, it's important to understand that at this point the dev(s) you are teaching are probably not yet convinced that this is the right way to code. The point where most devs seem to see the (green) light is when a test fails due to some code changes that they never thought would break any functionality. When the test that covers that functionality blows up, that's when you've got yourself a loyal TDD'er on your team. Or that's at least my experience, but as always; your mileage will vary :)

这篇关于你如何说服别人编写单元测试?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！