要求正式单元测试最有说服力的方式是什么？
这当然前提是单元测试是一件好事。 我们的项目有一定程度的单元测试，但充其量是不一致的。
您使用过或与您一起使用过的最有说服力的方法是什么，可以让每个人相信形式化的单元测试是一件好事，并且将其作为必需的确实符合我们从事的“大型”项目的最佳利益。 我不是开发人员，但我从事质量保证工作，希望提高所交付工作的质量，以确保其准备好进行测试。
通过形式化的单元测试，我只是谈论
- 识别要编写的单元测试
- 识别测试数据（或描述它）
- 编写这些测试
- 跟踪这些测试（并根据需要重新使用）
- 使结果可用
This certainly presupposes that unit testing is a good thing. Our projects have some level of unit testing, but it's inconsistent at best.
What are the most convincing ways that you have used or have had used with you to convince everyone that formalized unit testing is a good thing and that making it required is really in the best interest of the 'largeish' projects we work on. I am not a developer, but I am in Quality Assurance and would like to improve the quality of the work delivered to ensure it is ready to test.
By formalized unit tests, I'm simply talking about
- Identifying the Unit Tests to be written
- Identifying the test data (or describe it)
- Writing these tests
- Tracking these tests (and re-using as needed)
- Making the results available
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（14）
一个非常令人信服的方法是自己进行正式的单元测试，无论您的团队/公司做什么。 这可能需要您付出一些额外的努力，特别是如果您没有这种练习的经验。
当你可以证明你的代码更好并且你比其他开发人员更有效率时，他们就会想知道为什么。 然后向他们提供您最喜欢的单元测试方法。
一旦你说服了其他开发人员，就可以一起说服管理层。
A very convincing way is to do formalized unit test yourself, regardless of what your team/company does. This might take some extra effort on your side, especially if you're not experienced with this sort of practice.
When you can then show your code is better and you are being more productive than your fellow developers, they are going to want to know why. Then feed them your favorite unit testing methods.
Once you've convinced your fellow developers, convince management together.
我将 Maven 与 Surefire 和 Cobertura 我所有构建的插件。 实际的测试用例是使用 JUnit 创建的，DbUnit 和 EasyMock。
识别单元测试
我尝试遵循测试驱动开发，但说实话，我通常只对少数测试用例执行此操作，然后再回来为边缘和异常情况创建测试。
识别测试数据
DbUnit 非常适合为单元测试加载测试数据。
编写测试用例
我使用 JUnit 来创建测试用例。 我尝试编写自记录测试用例，但会使用 Javadocs 来注释一些不明显的内容。
追踪与追踪 提供结果
我使用 Surefire 插件将单元测试集成到我的 Maven 构建周期中，并使用 Corbertura 插件来测量这些测试所实现的覆盖率。 我总是生成并发布一个网站，其中包括 Surefire 和 Cobertura 报告，作为我日常构建的一部分，这样我就可以看到哪些测试失败/通过了。
I use Maven with the Surefire and Cobertura plugins for all my builds. The actual test cases are created with JUnit, DbUnit and EasyMock.
Identifying Unit Tests
I try to follow Test Driven Development but to be honest I usually just do that for the handful of the test cases and then come back and create tests for the edge and exception cases later.
Identifying Test Data
DbUnit is great for loading test data for your unit tests.
Writing Test Cases
I use JUnit to create the test cases. I try to write self documenting test cases but will use Javadocs to comment something that is not obvious.
Tracking & Making The Results Available
I integrate the unit testing into my Maven build cycle using the Surefire plugin and I use the Corbertura plugin to measure the coverage achieved by those tests. I always generate and publish a web-site including the Surefire and Cobertura reports as part of my daily build so I can see what tests failed/passed.
您可以从 Google 的一项举措中获得一些灵感。 他们的测试团队开始在厕所隔间内张贴示例、技巧和好处，以提高测试自动化优点的形象。
https://testing.googleblog.com/2007/01/介绍-testing-on-toilet.html
You could take some inspiration from an initiative at Google. Their test team started putting up examples, tips and benefits inside the toilet cubicles to raise the profile of the merits of test automation.
https://testing.googleblog.com/2007/01/introducing-testing-on-toilet.html
作为团队领导，我有责任确保我的程序员对他们工作的所有模块进行单元测试。 我想在这一点上，这甚至不是如何说服他们的问题，这是必需的。 有时候不是，大型项目也不是，总是如此。 单元测试是防止将某些东西投入生产而需要维护的第一道防线。 如果某些东西投入生产时还没有经过完全的单元和系统测试，那么它就会回来咬你。 我想我们支持这一点的政策之一是，如果它在生产中崩溃，或者导致问题，那么负责编码和测试该模块的程序员将是必须处理问题、进行清理的人等等。仅此一点就是一个相当好的激励因素。
另一个是关于骄傲。 我在一家大约有 75 名编码员的商店工作，尽管从某些标准来看这个规模很大，但它确实小到足以让我们所有人互相认识。 它也足够小，我们知道彼此正在做什么，当它确实转移到生产环境时，我们会意识到任何异常终止、故障等。如果你小心的话，进行单元和系统测试，移动某些东西的机会在不造成故障的情况下生产的显着增加。 将某些东西投入生产可能需要一两次时间，但未能实现，但不搞砸会带来巨大的回报。 当你把一个项目搬进去并且没有搞砸时，在走廊里听到祝贺真是太好了。
As a team lead, it is my responsibility to ensure that my programmers are doing unit testing on all the modules they work on. I suppose at this point, it's not even a question of how to convince them, it's required. Not sometimes, not on largish projects, all the time. Unit testing is the first line of defense against putting something in production that you will have to maintain. If something is put into production that has not been completely unit and system tested, then it will come back to bite you. I guess one of the policies we have here to support this is that if it blows in production, or causes problems, then the programmer responsible for coding and testing that module will be the one that has to take care of the problems, do the cleanup, etc. That alone is a fairly good motivator.
The other is that it is about pride. I work in a shop of about 75 coders, although that is large by some standards, it's really small enough for all of us to know one another. Its also small enough that we know what one another is working on, and when it does move to production, we are aware of any abends, failures, etc. If you are careful, do the unit and system testing, the chances of moving something to production without causing failures increases significantly. It may take a time or two of moving something to production and failing to realize it, but there are great rewards involved in not messing up. It's really nice to hear congratulations in the hallway when you move a project in and it doesn't screw up.
提醒您的团队或其他开发人员，他们是专业人士，而不是业余爱好者。 为我工作！
此外，它现在已成为行业标准。 如果没有单元测试经验，对于未来的潜在雇主来说，他们作为雇员的吸引力和价值就会降低。
Remind your team or the other developers that they're professionals, not amateurs. Worked for me!
Also, it's an industry standard these days. Without unit testing experience, they are less desirable and less valuable as employees to potential future employers.
在我的软件团队中，我们倾向于就这些问题编写一个小型业务案例，并将其提交给管理层，以便有时间创建和跟踪测试。 我们解释说，当关键时刻到来且一切都岌岌可危时，测试所花费的时间就得到了很好的弥补。 我们还设置了 Hudson 构建服务器来集中跟踪单元测试。 这使得开发人员更容易跟踪失败的测试并发现重复出现的问题。
On my software team, we tend to write a small business case on these issues and present them to management in order to have the time available to create and track tests. We explain that the time taken to test is well made up for when crunch time comes and everything is on the line. We also set up a Hudson build server to centralize the tracking of the unit tests. This makes it a lot easier for the developers to keep track of failing tests and to discover recurring problems.
教育和/或认证。
为您的团队成员提供测试领域的正式培训 - 也许包括认证考试（取决于您的团队成员和您自己对认证的态度）。 通过这种方式，您会将测试提升到更高的水平，并且您的团队成员将更有可能对测试采取专业态度。
Education and/or certification.
Give your team members a formal training in the field of testing - maybe with certification exam (depending on your team members and your own attitude towards certification). You'll take testing to a higher level that way, and your team members will be more likely to take a professional attitude towards testing.
令人信服和要求之间存在很大差异。
如果你找到一种方法说服你的同事来写它们——那就太好了。 但是，如果您创建一些正式的规则并要求他们编写单元测试，他们会找到一种方法来克服这个问题。 结果，您将得到一堆毫无价值的单元测试：每个可用的类都会有单元测试，并且它们将测试 setter 和 getter。
在制定和执行规则之前要三思而后行。 开发人员善于克服这些问题。
There is a big difference between convincing and requiring.
If you find a way to convince your colleagues to write them - great. However if you create some formalized rules and require them to write unit tests, they will find a way to overcome this. As a result you will get a bunch of unit tests which are worth nothing: There will be unit test for every single class available and they will test setters and getters.
Think twice before creating and enforcing rules. Developers are good at overcoming them.
第一次，你只需要继续写下来，并向人们展示这是值得的。 我在三个项目中发现这是说服人们的唯一方法。 一些不编码的人（例如初级项目经理）将无法看到其价值，直到它摆在他们面前。
First time around you just need to go ahead and write them and show people that it's worth it. I've found on three projects that it's the only way to convince people. Some people who don't code (e.g. junior project managers) won't be able to see the value until it's staring them right in the face.
因此，在我提出这个问题两年后，我发现一个意想不到的答案是，迁移到新的 SDLC 正是我们所需要的。 五年前，我们建立了第一个正式的 SDLC。 它改善了我们的情况，但遗漏了一些重要的事情，例如自动化。 我们现在正在建立一个新的 SDLC（在新的管理下），其中的租户之一是自动化。 不仅仅是自动化单元测试，还有自动化功能测试。
我想教训是我想得太小了。 如果您要改变创建软件的方式，请“全力以赴”并进行彻底的更改，而不是在您不习惯的情况下提出增量更改。
So, two years after I asked this question, I find that one unexpected answer was that by moving to a new SDLC was what was needed. Five years ago, we established our first formal SDLC. It improved our situation, but left out some important things, such as automation. We are now in the process of establishing a new SDLC (under new managment) where one of the tenants is automation. Not just automated unit tests, but automated functional tests.
I guess the lesson is that I was thinking too small. If you are going to change how you create software, go 'whole hog' and make a drastic change rather than propose incremental change if you are not used to that.
编写一堆单元测试并证明单元测试提高了您的生产力和代码质量。 如果没有某种证据，有时人们不会相信这是值得的。
Write a bunch of them and demonstrate that unit testing has improved your productivity and the quality of your code. Without some kind of proof, sometimes people won't believe it's worth it.
有时以身作则是最好的方法。 我还发现，这提醒人们，当事情处于测试阶段时，某些事情就不会发生。 下次有人要求你写一些东西时，无论如何都要进行测试。 最终，你的同事会嫉妒你可以轻松地更改代码并知道它仍然有效。
至于管理，您需要强调当您需要对未测试的代码库 X 进行更改时，由于发生核爆炸而浪费了多少时间。
许多开发人员没有意识到他们重构了多少，而没有确保他们在整个系统中保留行为。 对我来说，这是单元测试和 TDD 的最大好处。
唯一确定的是变化。 更改未测试的代码要求开发人员了解所有可能的行为副作用。 现实情况是，那些认为自己可以解读每一种排列的编码员，是通过痛苦的反复试验过程来做到这一点的，直到没有明显的问题为止。 此时他们会进行检查。
务实的程序员认识到他/她并不完美且无所不知，测试就像一张安全网，使他们能够快速、安全地走重构钢丝。
至于何时在新代码上编写测试，我必须尽可能地提倡。 花时间定义您希望系统的行为，并首先编写测试来表达这些更高级别的构造。 当想法具体化时，单元测试就会随之而来。
希望这可以帮助。
Sometimes by example is the best way. I also find that reminding people that certain things just dont happen when things are under test. Next time somebody asks you to write something, do it with tests regardless. Eventually your peers will be jealous of the ease by which you can change your code and know that it still works.
As for management you need to emphasise how much time gets wasted due to the nuclear explosion that occurs when you need to make a change to codebase X that isnt under test.
Many developers dont realise just how much they refactor without ensuring they are preserving behaviour across the entire system. For me this is the biggest benefit to unit testing and TDD in my opinion.
The only certainty is change. Changing code that is not under test requires the developer to be aware of every behavioural side effect possible. The reality is that the coders who think they can read into every permutation, does so by a pain staking process of trial and error until nothing breaks obviously. At this point they check in.
The pragmatic programmer recognizes that he/she is not perfect and all knowing, and that tests are like a safety net that allows them to walk the refactoring tightrope quickly and safely.
As for when to write test on greenfield code, I'd have to advocate as much as possible. Spend the time defining the behaviours that you want out of your system and write tests initially to express those higher level constructs. Unit tests can come as thoughts crystallize.
Hope this helps.
让我信服的事件是我们在连续三个版本中成功地使错误回归了三次。 一旦我意识到，作为一名程序员，如果我不在客户那里不断地修复琐碎的错误，那么我的工作效率会提高多少，而且我可能会有一种温暖的模糊感觉，同事的代码会按照他们声称的那样做，我就变得一个皈依者。
The event which convinced me was when we managed to regress a bug three times, in three consecutive releases. Once I realised how much more productive I was as a programmer when I wasn't constantly fixing trivial mistakes after they had gone to the client, and I could have a warm fuzzy feeling that colleagues code would do what they claimed it would, I became a convert.
回到我在大型机上进行 Cobol 开发的那一天，我们在我工作过的几家公司中虔诚地这样做，并且它被接受为你做事的方式，因为环境强制执行它。 我认为这是那个时代非常典型的方案，也许其中一些原因可能适用于您：-
像大多数大型机环境一样，我们有三个领域：开发、质量保证和生产。 程序员在那里进行开发和单元测试，一旦他们签字并感到高兴，该单元就会迁移到 QA 环境（带有测试和结果文档），由专门的 QA 人员对其进行系统测试。 QA 迁移的开发是一夜之间发生的正式步骤。 一旦经过质量检查，代码就会迁移到生产环境 - 我们几乎没有错误。
正确完成单元测试的动机是，如果您没有这样做并且 QA 人员发现了错误，那么很明显您没有完成这项工作。 因此，你的声誉取决于你的严谨程度。 当然，大多数人最终都会遇到偶尔的错误，但是始终生成可靠的经过测试的代码的程序员很快就会获得明星声誉，而那些生成有错误的代码的人也会受到关注。 推动力始终是提高你的游戏水平，因此产生的文化是推动第一次交付无错误代码的文化。
提取相关点 -
我确信您的环境会有所不同，但原理可能是可以翻译的。
Back in the day I did Cobol development on Mainframes we did this religiously in the several companies I worked in and it was accepted as the way you did things because the environment enforced it. I think it was a very typical scheme for the era and maybe some of the reasons might be applicable to you:-
Like most mainframe environments we had three realms, development, Quality Assurance and Production. Programmers developed in development and unit tested there, and once they signed off and were happy the unit was migrated to the QA environment (with the test and results docs) where it was system tested by dedicated QA staff. The development to QA migration was a formal step which happened overnight. Once QA'ed the code was migrated to Production - and we had very few bugs.
The motivation to get the unit testing done and right was that if you didn't and a bug was found by QA staff it was obvious that you hadn't done the work. Consequently your reputation depended on how rigorous you were. Of course most people would end up with the occasional bug, but coders who produced solid tested code all the time soon got a star reputation and those who produced buggy code got noticed too. The push would be always to up your game, and consequently the culture produced was one that pushed towards bug free code delivered first time.
Extracting pertinent points -
I'm sure your environment will differ but the principals might be translatable.