将单元测试引入现有项目
我正在开发一个现有的 Java EE 项目，其中包含在 Eclipse 中开发的各种 Maven 模块，这些模块捆绑在一起并使用 Java 1.6 部署在 JBoss 上。我有机会准备任何框架并记录如何将单元测试引入项目。
您能否提供任何建议...
- JUnit 是我期望的起点，这仍然是 Java 开发人员事实上的选择吗？
- 有什么值得设置为标准的模拟框架吗？ JMock？
- 应该设置的任何规则 - 代码覆盖率，或确保它是单元测试而不是集成测试。
- 有什么工具可以生成外观精美的输出以供项目经理奉承吗？
还要别的吗？提前致谢。
I'm working on an existing Java EE project with various maven modules that are developed in Eclipse, bundled together and deployed on JBoss using Java 1.6. I have the opportunity to prepare any framework and document how unit testing should be brought to the project.
Can you offer any advice on...
- JUnit is where I expect to start, is this still the defacto choice for the Java dev?
- Any mocking frameworks worth setting as standard? JMock?
- Any rules that should be set - code coverage, or making sure it's unit rather than integration tests.
- Any tools to generate fancy looking outputs for Project Managers to fawn over?
Anything else? Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
当心。用于显示单元测试计数、覆盖率、代码质量指标、行数、签入计数等指标的精美工具在某些项目经理手中可能是危险的。项目经理（不了解软件开发的实际情况）可能会沉迷于指标，而没有意识到：
他们没有给出项目健康和进度的真实情况，并且
他们可能对个别团队成员的表现提供完全错误的情况。
您可能会遇到愚蠢的情况，即经理向开发人员发出这样的消息：他们应该（例如）尝试实现代码的最大单元测试覆盖率，而这是根本没有保证的。时间花在无意义的工作上，重要的工作没有完成，错过了最后期限。
代码覆盖率对于可能脆弱/有错误的代码部分更为重要。可接受的覆盖水平应该反映这一点。
单元测试与集成测试取决于您正在构建的系统的性质和复杂性。
事后添加大量单元级别测试可能是浪费时间。这只应该对被识别为有问题/需要维护工作的类进行。
事后添加集成级别测试很有用，特别是在项目原始开发人员不再存在的情况下。一个像样的集成测试套件有助于增强您的信心，相信某些更改不会破坏重要的系统功能。但这需要谨慎行事。测试网站外观和感觉的 N 级测试套件对于维护来说可能是一场噩梦……并且会阻碍进展。
Be careful. A fancy tool for displaying metrics on unit test counts, coverage, code quality metrics, line counts, check-in counts and so on can be dangerous in the hands of some project managers. A project manager (who is not in touch with the realities of software development) can get obsessed with the metrics, and fail to realize that:
they don't give the real picture of the project's health and progress, and
they can give a completely false picture of the performance of individual team members.
You can get silly situations where a manager gives the developers the message that they should (for example) try to achieve maximal unit test coverage for code where this is simply not warranted. Time is spent on pointless work, the important work doesn't get done, and deadlines are missed.
Code coverage is more important for parts of the code that are likely to be fragile / buggy. Acceptable coverage levels should reflect this.
Unit tests versus integration tests depends on the nature and complexity of the system you are building.
Adding lots of unit level tests after the fact is probably a waste of time. It should only be done for class identified as being problematic / needing maintenance work.
Adding integration level tests after the fact is useful, especially if the projects original developers are no longer around. A decent integration test suite helps to increase your confidence that some change does not break important system functionality. But this needs to be done judiciously. A test suite that tests the N-th degree of a website's look and feel can be a nightmare to maintain ... and impediment to progress.
关于单元测试框架，主要有两种：jUnit和TestNG。两者都有各自的优点，并且性能相同。 jUnit 的主要优点（在我看来）是它默认集成的 Eclipse 插件，允许轻松调用测试。
关于模拟框架，我认为它们不是测试方法的必需部分。当然它们很有用，但它们解决了一个特定的目的：测试行为（与测试接口相反 - jUnit 允许的）。使用模拟框架，您可以测试特定类如何实现特定接口。您愿意吗？显然，你会首先需要它吗？我不知道，
我发现唯一有用的规则很简单（一如既往）：“总是测试至少一次损坏的代码。”考虑一下您的错误跟踪器。每次遇到错误时，都必须进行单元测试，以确保没有回归，在我看来，这是获得高质量代码的更快方法
。你足以安装一个持续集成服务器（Hudson，显然它每次都会运行你的所有测试套件）。代码提交后，为了确保没有副作用，它会生成显示测试运行次数的图表，等等。这个持续集成服务器将真正成为您快速测试的伙伴。
Concerning the unit testing framework, there are mainly two of them : jUnit and TestNG. Both have theuir advantages, and both are equally performant. The main dvantage of jUnit is (to my mind) its default incoproration of an Eclipse plugin allowing easy tests calling.
Concerning the mocking framework, I don't find them to be a required part of your testing approach. Of course they're useful, but they solve a specific purpose : testing a behaviour (as opposite to testing an interface - what jUnit allows. With mocking frameworks, you're able to test how a specific class implements a specific interface. Will you need it ? Obviously. Will you need it first ? I don't know.
Concerning the rules, the only one I've found to be useful is simple (as always) : "always test code that broke at least once.". Consider your bug tracker. Each time a bug is encountered, there must be a unit test ensuring there is no regression. It's, to my mind, the faster way to have quality code.
Concerning the fancy- and efficient - output, I can recommend you enough to install a continous integration server (Hudson, obviously). It will run all your test suite each time code is commited, to ensure there are no side effects. it will generate graphs shoiwing the number of test run, and so on. it also can integrate code coverage tools and graphs. This continuous integration server will really become fast your testing buddy.
这是一个复杂的问题，因此仅就我们在 $work 的实践做一些说明：
This is a complex question, so just a few notes about our practice at $work:
如果您还没有这样做，请阅读有效使用旧代码 迈克尔·羽毛。
If you haven't done so already, read Working Effectively with Legacy Code by Michael Feathers.
我一直在对 C++ 项目进行单元测试改造，但这并不令人愉快。
我做的第一件事就是确定大部分“动作”发生的位置。然后使用它开始对可以轻松测试的功能进行单元测试。
然后，一旦您有了更简单的函数，您就可以开始考虑病毒式地扩展覆盖范围 - 攻击依赖项较少的函数，在调试器中运行它们几次，看看传入的值是什么，然后使用这些值编写单元测试确保你没有破坏任何东西。
不要指望快速修复 - 需要 3 周（每天 6 小时，每周 5 天）才能获得 20% 的覆盖率，但代码在该代码中花费了 80% 的时间，所以我认为时间花得值，并且已经发现有相当多的错误。
I've been retrofitting unit tests to a C++ project and it is not pleasant.
First thing I did was to identify where most of the 'action' occurs. Then use that to start putting unit tests on the functions that can be test easily.
Then once you have the easier ones you can start looking at expanding the coverage virally - attack the functions that have fewer dependancies, run through them a few times in a debugger seeing what values are passed in and then write unit tests with those values to make sure you don't break anything.
Don't expect a quick fix - it's taken 3 weeks (6hr days, 5 days a week) to get 20% coverage but the code spends 80% of the time in that code so I think it has been time well spent and has uncovered quite a few bugs.
关于测试覆盖率，我认为当您将单元测试引入现有项目时，开始设置覆盖率期望还为时过早。您应该首先确保您实际上可以集成测试框架并从覆盖率工具获取报告。完成此操作后，您可以开始监控覆盖范围，然后您可以考虑目标。
Regarding test coverage, I think that when you're bringing in unit testing to an existing project it's too early to start setting coverage expectations. You should start by ensuring that you actually can integrate the test framework and get reports from the coverage tools. Once you've done that you can start monitoring coverage, and then you can consider targets.