强制开发人员进行单元测试
首先介绍一点背景。我工作的公司编写基于 Web 的软件，该软件是为我们的客户（即 ASP（应用程序服务提供商））提供的托管解决方案。我们正在采用 Scrum 等敏捷实践，并执行冲刺来为我们的产品构建新功能。
我是 TDD（测试驱动设计）的支持者，作为我在冲刺中交付的一部分，我总是编写测试，并且总是将它们与构建集成（即 ccnet）；然而，其他开发商并没有遵循这种做法，也没有强制执行。
强制开发团队提供单元测试作为冲刺交付内容的一部分是一个好习惯吗？
First a little background. The company I work for writes web based software that is a hosted solution for our customers (ie ASP (Application Service Provider)). We are adopting agile practices such as Scrum and we execute sprints to build new features for our product.
I am a proponent of TDD (Test Driven Design), and as a part of what I deliver in a sprint I always write tests and I always get them integrated with the build (ie ccnet); however the other developers do not follow this practice and it is not enforced.
Is it a good practice to force a development group into providing unit tests as a part of what is delivered in a sprint?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（10）
除非您是权威人士，否则您能做的最好的事情就是让他们相信测试套件的价值。
如果开发人员没有看到这个问题的正确处理，就很难让他们认识到这个问题。
尝试与其他开发人员结对，并向他们展示首先编写测试所带来的好处和清晰度。如果您不这样做，他们可能会编写所有代码，使其正常工作，然后编写测试。因此，从他们的角度来看，这感觉只是一项额外的任务，无助于他们完成工作。
还要记住，人们常常不明白如何编写好的测试。更重要的是，有些人不知道如何使用 jmock 等工具，这可能会导致他们陷入困境并放弃编写测试。
Unless you are a position of authority, the best thing you can do is to convince them of the value of the test suite.
It's very difficult to get developers to see the light on this issue if they aren't seeing it done right.
Try to pair with another developer and show them the benefits and the clarity that comes from writing the tests FIRST. If you don't do this, they are likely to write all of their code, get it working, and then write tests. So, from their point of view, it will feel like simply an extra task that doesn't help them get things done.
Also keep in mind that people often do not understand how to write good tests. Even more, some do not know how to make use of tools like jmock, which can lead to them getting stuck and giving up on writing a test.
在我看来，把任何事情强加给任何人都不是一个好的做法。我会利用每一个机会向他们展示 TDD 的好处。这应该会自动让团队的其他成员自愿练习 TDD。
Forcing anything onto anybody is not a good practise in my view. I would show them the benefits of TDD at every opportunity I get. This should automatically get the rest of the team to voluntarily practise TDD.
您不需要口头上的单元测试，您需要全心全意的单元测试。这不是可以强迫的事情。您需要做的是随着时间的推移影响您的队友，让他们看到单元测试的好处并发展单元测试文化。
首先，您需要了解不同的人会因不同的原因而改变。在跨越鸿沟术语中，有远见的人会采用新技术，因为它们更好，但实用主义者会采用新的技术技术要么是因为它们解决了当前存在的问题/痛苦，要么是因为其他人都在采用它。
然后你的任务是展示单元测试如何解决你的团队当前感受到的痛苦。当你一个接一个地赢得人们的支持时，你最终会达到一个转折点，单元测试成为常态，每个人都同意它。然而，如果您不能将单元测试与您的团队感受到的痛苦联系起来，那么您说服他们的努力可能会失败。
You don't want lip-service unit testing, you want whole-hearted unit testing. That isn't something that can be forced. What you need to do is influence your teammates over time to see the benefits of unit testing and to develop a unit testing culture.
To start with you need to understand that different people change for different reasons. In Crossing the Chasm terms, visionaries will adopt new techniques because they are better, but pragmatists adopt new techniques either because they solve a problem/pain the currently have or because everyone else is adopting it.
Your mission then it to show how unit testing can solve a pain your team currently feels. As you win over people one-by-one eventually you can reach a tipping point where unit testing is the norm and everyone goes along with it. However if you can't tie unit testing to a pain your team feels then your efforts to convince them will likely fail.
考虑到单元测试从长远来看可以提高代码和软件质量，我想说，是的，让开发人员提供单元测试是一种很好的做法——无论它是否是某种冲刺的一部分。
我看到的单元测试的两个主要障碍是：
要回答第一点，我想您必须提供某种演示/形成；如果你能让开发人员了解为什么单元测试有用，他们就会喜欢它们，并使用/开发它们；但他们需要了解为什么这些有用：除非你是他们的老板，否则你不能强迫人们开发单元测试。
而且，即使你是他们的老板，如果他们被迫的话，他们也可能不会做得最好：如果人们理解为什么以及如何做，单元测试通常会做得更好！
要回答第二点......好吧，您显然需要让您的开发人员有一些“特殊”时间来开发单元测试；顺便说一句，这可能意味着更少的时间进行手动测试。
另一件事是：很难知道“测试什么”和“如何测试”：您需要向同事解释/演示：有些东西无法测试，有些东西不需要测试，并且有些东西不是“可单元测试的”——好吧，我想，除非你的软件设计得非常好^^
Considering unit-testing improves code and software quality on a long term, I would say that, yes, it is good practice to have your developpers provide unit-tests -- be it part of some kind of sprint or not.
The two main barriers to unit-tests I've seen are :
To answer the first point, you'll have to provide some sort of demonstration / formation, I suppose ; if you can get developpers to see why unit-tests are useful, they will like them, and use/develop them ; but they need to seen why those are useful : unless you are their boss, you cannot force people to develop unit-tests.
And, even if you are their boss, they will probably not do the best possible job if they are being forced : unit-testing is often done better if people understand why and how !
To answer the second point... Well, you obviously need to get your developpers some "special" time to developp unit-tests ; it can mean less time to do manual testing, btw.
Another thing is : it is hard to know "what to test", and "how to test" : you will need to explain / demonstrate that to your colleagues : some things cannot be tested, some things don't need to be, and some things are not "unit-testable" -- well, I suppose, unless you software is really well engineered ^^
我过去曾在很多工作和合同中担任过这个职位，所以我最终灰心丧气，通过倡导开发驱动开发。
我发现，当大多数经理接受 XP 时，他们是在放弃文档，而不是真正执行 TDD。大多数团队中的程序员都会因为快速解决缺陷而获得奖励，大约十分之一的经理有勇气与高级管理层对抗，倡导产品的整体质量，而不是底层的产品质量。 -本季度的经营方式。毕竟，大多数不计报酬的软件工作都是公司赞助的，弗洛伊德证明公司是疯狂的。
或者至少，他应该这样做。
I've gotten in that position on many jobs and contracts in the past, so I've finally gotten discouraged and embraced the darkness by advocating Development Driven Development.
I've found that when most managers embrace XP, they're embracing throwing out the documentation, not really doing TDD. Programmers on most teams are rewarded for quick hacks that get the defect out of their queue, and it's one manager in about ten who has the guts to stand up to senior management as an advocate of the overall quality of the product as opposed to the bottom-line-for-this-quarter way of doing business. After all, most software jobs that pay anything are corporate sponsored, and Freud proved that corporations are insane.
Or at least, he should have.
Joel 在软件方面有一篇很棒的文章，名为当你只是一个咕噜者时完成事情< /a>.他应用于联合测试的策略如下：
Just Do It
我认为最重要的是。定期编写测试，不要让它们看起来好像您自己将它们视为开发的一小部分。
利用病毒式营销的力量
如果您在其他人的代码中发现错误，请编写一个测试来触发该错误并将两者呈现给他。也许他明白你的意思。
创造卓越的口袋
确定对这个想法持开放态度但不太确定如何进行单元测试的团队成员，并设置一些测试类，直到他们每个人都知道如何去做。然后转向其他人。一旦你不再是唯一的人，事情就会变得容易得多。
消灭 Bozos
有些团队成员几乎不可能编写测试。也许应该通过定期用新的提交来破坏他们的代码来解决这些问题 - 然后指出，因为他们没有测试，所以你很难注意到。
There is a great Joel on Software article on this called Getting Things Done When You're Only a Grunt. His strategies applied to united testing would be the following:
Just Do It
Most important, I think. Regularly write tests, do not make it appear as if you yourself see them as a minor part of development.
Harness the Power of Viral Marketing
If you see an error in someone else's code, write a test that triggers it and present both to him. Maybe he sees your point.
Create a Pocket of Excellence
Identify the team members who are open to the idea but not quite sure how to work with unit tests and set up a number of test classes until everyone of them knows how to do it. Then turn towards the other ones. Things are a lot easier to establish once you are not the only one anymore.
Neutralize The Bozos
There will be team members who are almost impossible to get to write tests. Maybe those should be dealt with by regularly breaking their code with a new commit - and then pointing out that since they don't have tests it was hard for you to notice.
这取决于您的版本控制，但是有一些版本控制软件使您能够在签入或合并到生产分支之前运行脚本。如果单元测试失败，它不会让开发人员签入。
it depends on your Version Control, but there are Version Control Software that enable you to run scripts before check-in or before merge to the Production branch. and it will not let the developer check in if the unit testing is failed.
首先，与您的经理交谈。如果他确信测试是一件好事，请将覆盖率测试添加到您的构建系统中。如果单元测试的覆盖率低于特定水平，您可以将其视为失败的构建。这为您的同事提供了一种衡量标准，一种查看何时无法交付测试代码的方法。
就您而言， NCover 似乎 很好地集成到 CC.NET。
First, talk to your manager. If he is convinced that testing is a good thing, add a coverage test to your build system. If the coverage of your unit tests falls below a certain level, you can handle it as a failed build. This gives your colleagues a measure, a way to see when the fail to deliver tested code.
In your case, NCover seems to integrate nicely into CC.NET.
创建一个您希望开发人员实现的矩阵。
确保每个故事都有一个用于创建单元测试的子任务。
Create a matrix that you want developers to achieve.
Make sure there is a subtask for Unit test creation for every story.
不。根据我的经验，TDD 在实践中并不是那么有用。我有时将它用于真正通用的基础类（如几何或通用数据结构），这些类自然适合自动化测试。但对于 UI 组件或业务逻辑，我发现它的麻烦大于它的价值。
No. In my experience, TDD isn't all that useful in practice. I sometimes use it for really general fundamental classes (like geometry or generic data structures) that lend themselves naturally to automated tests. But for UI components or business logic, I find it's more trouble than it's worth.