从java类中删除测试代码
有没有办法从我的 Java 类中剥离 JUnit @Test 代码。 目前我将测试代码嵌入到与要测试的源代码相同的文件中 （是的，我知道这很糟糕，但它是我继续维护测试代码的动力）
我想从代码中剥离测试方法，构建二进制文件并部署。
谢谢
Is there a way to strip the JUnit @Test code from my Java class.
At the moment I embedded the test code in the same file as the source code to be tested
(Yes I know it's bad, but it is an incentive for me to keep maintaining my test code)
I'd like to strip the test methods from the code, build the binary and deploy.
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
不，我不知道你如何做到这一点，但我可以告诉你为什么你可能不想首先使用这种方法。
@Test。这些只是我能想到的一些原因......为什么不首先避免这个问题呢？
No, I don't know how you can do that, but I could tell you why you might not want to use this approach in the first place.
@Test.These are just some of the reasons I can think of... why no just avoid the problem in the first place?
据我所知，没有特定的工具可以完成这项任务。
您可能需要“慢慢来”并使用您最喜欢的文本编辑器/IDE 来艰难地进行更改。 （也许这个练习会教你更加注意良好的实践/良好的风格......）
There are no specific tools to do this task that I'm aware of.
You'll probably need to "take your licks" and make the changes the hard way with your favorite text editor / IDE. (And maybe this exercise will teach you to pay more heed to good practice / good style ... )
有一些工具可以帮助您做到这一点（旨在加密字节码的东西也往往会删除未使用的事物）。
不过我不建议这样做。很高兴您找到了一种鼓励自己不断测试代码的方法（事实上很棒！）。然而，正如您所发现的，您选择的方式并不那么好。将测试代码与代码本身分开的原因有很多。
我要做的是（一次一个类）：
1）硬着头皮制作一组并行的类进行测试
2）将前面有@Test的任何内容移动到新类
3) 移走任何其他阻止测试编译/运行的内容。
然后使用代码覆盖率工具（我喜欢 Cobertura 但还有其他工具）让您直观地了解你的代码有多少经过了测试。再加上在运行代码之前编写测试的想法，你应该做得很好。
基本上，这是一种非常公式化的工作方式。如果您遵循编码和代码覆盖率的规定，然后修复覆盖率较差的地方，您应该会发现它就像测试代码在类中一样简单。这都是习惯 - 好习惯比坏习惯好:-)
There are some tools that might help you do this (things that aim to encrypt your bytecode also tend to remove unused things).
However I would NOT advise doing that. It is good that you found a way to encourage yourself to keep the code tested (great infact!). However, as you have found out, the way you chose isn't all that good. There are many reasons to keep the test code separate from the code itself.
What I would do is (one class at a time):
1) bite the bullet and make a parallel set of classes for testing
2) move anything that has an @Test before it to the new classes
3) move over anything else that keeps the tests from compiling/running.
Then make use of a code coverage tool (I like Cobertura but there are others) to give you a visual of how much of your code is tested. Add to that the idea of writing the tests before you run the code and you should do well.
Basically this is a very formulated way of working. If you follow the regiment of coding and code coverage and then fix the places where the coverage is poor you should find it just as easy as if the test code is in the class. It is all habit - and good habits are better than bad :-)