删除或注释掉不工作的 JUnit 测试?
我目前正在为遗留应用程序构建 CI 构建脚本。有零星的 JUnit 测试可用,我将把所有测试的 JUnit 执行集成到 CI 构建中。但是,我想知道如何处理在非维护的 JUnit 测试中遇到的 100 多次失败。我是否应该:
1) 注释掉它们,因为它们似乎具有合理的(如果没有维护)业务逻辑,希望有人最终取消注释并修复它们
2) 删除它们,因为不太可能有人会修复它们和注释掉的代码只会被忽略或永远混乱
3)追踪那些把这些烂摊子留在我手中的人,并用代码的打印输出敲打他们的头(由于长方法的气味,这将足够适合这项任务)同时宣扬维护良好且经过单元测试的代码库的好处
I'm currently building a CI build script for a legacy application. There are sporadic JUnit tests available and I will be integrating a JUnit execution of all tests into the CI build. However, I'm wondering what to do with the 100'ish failures I'm encountering in the non-maintained JUnit tests. Do I:
1) Comment them out as they appear to have reasonable, if unmaintained, business logic in them in the hopes that someone eventually uncomments them and fixes them
2) Delete them as its unlikely that anyone will fix them and the commented out code will only be ignored or be clutter for evermore
3) Track down those who have left this mess in my hands and whack them over the heads with the printouts of the code (which due to long-method smell will be sufficently suited to the task) while preaching the benefits of a well maintained and unit tested code base
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(8)
如果它们编译但失败:将它们留在里面。这将使您在使用 CI 时获得一段时间以来测试改进的良好历史记录。如果测试无法编译但破坏了构建,请将其注释掉并敦促开发人员修复它们。
这显然并不排除使用选项 3(打他们的头),无论如何你都应该这样做,无论你对测试做了什么。
If they compile but fail: leave them in. That will get you a good history of test improvements over time when using CI. If the tests do not compile but break the build, comment them out and poke the developers to fix them.
This obviously does not preclude using option 3 (hitting them over the head), you should do that anyway, regardless of what you do with the tests.
您现在绝对应该以某种方式禁用它们。无论是通过注释、删除(假设您可以从源代码管理中将它们恢复)还是其他方式来完成,都取决于您。您不希望这些失败的测试成为尝试提交新更改的人的障碍。
如果你觉得自己可以修复的问题足够少,那就太好了——那就去做吧。如果它们太多,那么我会倾向于使用“众包”方法。为每个失败的测试提交一个错误。如果可能的话,尝试将这些错误分配给测试/测试代码的实际所有者/作者,但如果这太难确定,那么只要告诉人们重新分配错误分配给他们的错误,随机选择就可以了。然后鼓励人们修复这些错误,要么给他们一个截止日期,要么定期通知每个人进展情况并鼓励他们修复所有错误。
You should definitely disable them in some way for now. Whether that's done by commenting, deleting (assuming you can get them back from source control) or some other means is up to you. You do not want these failing tests to be an obstacle for people trying to submit new changes.
If there are few enough that you feel you can fix them yourself, great -- do it. If there are too many of them, then I'd be inclined to use a "crowdsourcing" approach. File a bug for each failing test. Try to assign these bugs to the actual owners/authors of the tests/tested code if possible, but if that's too hard to determine then randomly selecting is fine as long as you tell people to reassign the bugs that were mis-assigned to them. Then encourage people to fix these bugs either by giving them a deadline or by periodically notifying everyone of the progress and encouraging them to fix all of the bugs.
持续显示红色的 CI 系统毫无价值。主要好处是保持质量标准,如果没有过渡来标记质量下降,那么这会变得更加困难。
因此,当前的工作应该是禁用失败的测试,并为每个测试创建一个跟踪票/工作项。无论你如何进行分类,这些问题中的每一个都会得到解决——如果没有人关心测试,那就放弃它。如果故障代表需要在发货前解决的问题,则禁用测试。
一旦处于这种状态,您现在可以依靠 CI 系统来告诉您需要采取紧急行动 - 回滚最后的更改,或者立即让团队修复问题,或者其他什么。
A CI system that is steady red is pretty worthless. The main benefit is to maintain a quality bar, and that's made much more difficult if there's no transition to mark a quality drop.
So the immediate effort should be to disable the failing tests, and create a tracking ticket/work item for each. Each of those is resolved however you do triage - if nobody cares about the test, get rid of it. If the failure represents a problem that needs to be addressed before ship, then leave the test disabled.
Once you are in this state, you can now rely on the CI system to tell you that urgent action is required - roll back the last change, or immediately put a team on fixing the problem, or whatever.
我不知道您在公司的职位,但如果可能的话,请将它们保留下来,并将问题作为错误记录在您的票务系统中。让开发人员自行修复它们或删除测试。
如果这不起作用,请删除它们(您有版本控制,对吧?)并用诸如“删除了显然不会被修复的失败的 junit 测试”之类的评论或更礼貌的内容来关闭票证。
关键是,junit 测试是应用程序代码,因此应该可以工作。这就是开发商获得报酬的原因。如果测试不再合适(测试了不再存在的东西),开发人员应该发出信号并删除测试。
I don't know your position in the company, but if it's possible leave them in and file the problems as errors in your ticket system. Leave it up to the developers to either fix them or remove the tests.
If that doesn't work remove them (you have version control, right?) and close the ticket with a comment like 'removed failing junit tests which apparently won't be fixed' or something a bit more polite.
The point is, junit tests are application code and as such should work. That's what developers get paid for. If a test isn't appropriate anymore (something that doesn't exist anymore got tested) developers should signal that and remove the test.
如果您使用 Junit 4,您可以使用 @Ignore 注释。
如果您使用 JUnit 3,您只需重命名测试,这样它们就不会以
test
开头。另外,尝试修复您正在修改的功能的测试,以免使代码变得更大。
If you use Junit 4 you can annotate that tests with @Ignore annotation.
If you use JUnit 3 you can just rename tests so they don't start with
test
.Also, try to fix tests for functionality you are modifying in order to not make code mess larger.
遵循不破窗原则并采取一些行动问题的解决方案。如果您无法修复测试,至少:
然后,为了防止将来发生这种情况,请安装类似于Hudson 游戏插件。人们在持续集成期间获得分配的分数,例如
非常酷的工具,可以创建关于单元的责任感团队内进行测试。
Follow the no broken window principle and take some action towards a solution of the problem. If you can't fix the tests, at least:
Then to prevent such situation from happening in the future, install a plug in similar to Hudson Game Plugin. People gets assigned points during continuous integration, e.g.
Really cool tool to create a sense of responsibility about unit tests within a team.
失败的 JUnit 测试表明
无论哪种方式,您都需要修复/审查测试/源。因为听起来你的工作是创建 CI 系统而不是修复测试,所以在你的位置上我会在测试中留下定时炸弹。您可以非常喜欢使用 JUnit 4 的带注释方法(例如
@IgnoreUntil(date="2010/09/16")
)和自定义运行程序,因此您也可以简单地添加一个 if 语句每个测试的第一行:其中
isBeforeTimeBomb()
可以简单地检查当前日期与您选择的未来日期。然后,您按照此处其他人给出的建议,并通知您的开发团队,构建现在是绿色的,但可能会在 X 天内爆炸,除非修复了定时炸弹测试。The failing JUnit tests indicate that either
Either way you need to fix/review the tests/source. Since it sounds like your job is to create the CI system and not to fix the tests, in your position i would leave a time-bomb in the tests. You can get very fancy with annotated methods with JUnit 4 (something like
@IgnoreUntil(date="2010/09/16")
) and a custom runner, so or you can simply add an an if statement to the first line of each test:Where
isBeforeTimeBomb()
can simply check the current date against a future date of your choosing. Then you follow the advice given by others here and notify your development team that the build is green now, but is likely to explode in X days unless the timebombed tests are fixed.