我们的项目包含 2600 个类文件 - 我们应该从哪里以及如何开始编写 junit 测试？
我们的项目包含 2600 个类文件，我们决定开始使用自动化测试。
我们知道我们应该早点开始这2599个类文件，但是大型项目应该如何以及从哪里开始编写测试呢？
随机选择一个班级然后就去？
知道什么是重要的？有没有什么好的工具可以使用？
Our project contains 2600 class files and we have decided to start using automated tests.
We know we have should have started this 2599 class files ago, but how and where should large projects start to write tests?
Pick a random class and just go?
What's important to know? Are there any good tools to use?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
在更改某些内容之前以及遇到的每个错误都编写单元测试。
换句话说，测试您当前正在使用的功能。否则，将花费大量时间和精力为所有类编写测试。
Write a unit test before you change something, and for every bug you encounter.
In other words, test the functionality you are currently working on. Otherwise, it is going to take a lot of time and effort to write tests for all classes.
开始为每个提交的错误编写测试（编写测试，观察它失败，修复错误，再次测试）。还要首先测试新功能（它们更有可能出现错误）。一开始会很慢，但随着测试基础设施的发展，它会变得更容易。
如果您使用的是 java 5 或更高版本，请使用 junit 4。
了解单元测试、集成测试和验收测试的区别。还要看看嘲笑。
Start writing tests for each bug that is filed (Write the test, watch it fail, fix the bug, test again). Also test new features first (they are more likely to have errors). It will be slow in the beginning, but as your test infrastructure grows, it will become easier.
If you are using java 5 or higher, use junit 4.
Learn about the difference of unit tests, integration tests and acceptance tests. Also have a look at mocking.
其他答案提供了有用的建议，但我错过了对基本原则的明确阐述：努力最大化你的努力的收益。在很大程度上用单元测试覆盖大型遗留代码库需要大量时间和精力。您希望从一开始就最大化您的努力成果。这不仅可以在早期提供有价值的反馈，还有助于说服/保持管理层和其他开发人员的支持，让他们相信这些努力是值得的。
因此，
Other answers have given useful advice, but I miss a clear articulation of the underlying principle: strive to maximize the benefit from your efforts. Covering a large legacy codebase with unit tests to a significant extent takes a lot of time and effort. You want to maximize the outcome of your effort from the start. This not only gives valuable feedback early on, but helps convincing / keeping up the support of both management and fellow developers that the effort is worth it.
So
不要先尝试单元测试。进行覆盖大面积代码的系统测试（端到端测试）。为所有新代码编写单元测试。
这样您就可以通过系统回归测试来稳定旧代码。随着越来越多的新代码出现，没有单元测试的代码部分开始消失。在没有进行系统测试的情况下为旧代码编写单元测试很可能会破坏代码，并且由于编写代码时没有考虑到可测试性，因此需要做大量的工作来证明其合理性。
Don't try unit tests first. Do system tests (end-to-end-tests) that cover large areas of code. Write unit tests for all new code.
This way you stabilize the old code with your system regression tests. As more and more new code comes in the fraction of code without unit tests begin to fade away. Writing unit tests for old code without the system tests in place will likly break the code and will be to much work to be justified as the code is not written with testability in mind.
您可以找到 Michael Feathers 的书有效地使用旧代码< /a> 有用。
You may find Michael Feathers' book Working Effectively with Legacy Code useful.
您现在相当愚蠢，但编写测试来支持您拥有的最关键的代码。例如，如果您的代码允许基于用户权限的功能，那么这是一个大问题 - 测试一下。将名称进行驼峰命名并将其写入日志文件的例程？没那么多。
“如果这段代码被破坏了，它会变得多么糟糕”是一个很好的试金石。
答案之一是“我们的内部维护屏幕在 IE6 上看起来很糟糕”。
另一个答案是“我们会向每个客户发送 10,000,000 封电子邮件”。
先考哪门课，呵呵。
You're fairly dorked now, but write tests that bolster the most critical code you have. For example if you have code that allows functionality based upon users' rights, then that's a biggy - test that. The routine that camelcases a name and writes it to a log file? Not so much.
"If this code broke, how much would it suck" is a good litmus test.
"Our internal maintenance screens would look bad on IE6" is one answer.
"We'd send 10,000,000 emails to each of our customers" is another answer.
Which classes would you test first, hehe.
您可能会发现这本书相关且有趣。作者在这里解释了如何完全按照您的要求进行操作。
http://my.safaribooksonline.com/0131177052
You might find this book relevant and interesting. The author explains how to do exactly what you ask for here.
http://my.safaribooksonline.com/0131177052
哦，还有一件事 - 单元测试数量不足比没有好得多。如果您能做的只有这些，请一次添加几个。不要放弃。
Oh, and one more thing - having an insufficient number of unit tests is far better than having none. Add a few at a time if that's all you can do. Don't give up.