为什么要使用 JUnit 进行测试? [英] Why use JUnit for testing?

问题描述

也许我的问题是一个新手问题，但我无法真正理解在什么情况下我会使用 junit?

Maybe my question is a newbie one, but I can not really understand the circumstances under which I would use junit?

无论我编写简单的应用程序还是更大的应用程序，我都会使用 System.out 语句测试它们，这对我来说很容易.

Whether I write simple applications or larger ones I test them with the System.out statements and it seams quite easy to me.

如果我们仍然必须调用相同的方法，检查它们返回的内容，然后我们有注释所有内容的开销，为什么要使用 JUnit 创建测试类，在项目中创建不必要的文件夹?

Why create test-classes with JUnit, unnecessary folders in the project if we still have to call the same methods, check what they return and we then have an overhead of annotating everything?

为什么不编写一个类并使用 System.out 立即测试它而不创建测试类?

Why not write a class and test it at once with System.out but not create Test-classes?

附注.我从未参与过我刚刚学习的大型项目.

PS. I have never worked on large projects I am just learning.

那么目的是什么?

推荐答案

那不是测试，而是手动查看输出"(在商业中称为 LMAO).更正式地说，它被称为手动查找异常输出"(LMFAO).^{(见下方注释)}

That's not testing, that's "looking manually at output" (known in the biz as LMAO). More formally it's known as "looking manually for abnormal output" (LMFAO). ^{(See note below)}

每当您更改代码时，您都必须为受这些更改影响的所有代码运行应用和 LMFAO.即使在小型项目中，这也是有问题且容易出错的.

Any time you change code, you must run the app and LMFAO for all code affected by those changes. Even in small projects, this is problematic and error-prone.

现在可以在任何时候更改代码时扩展到 50k、250k、1m LOC 或更多，以及 LMFAO.这不仅令人不快，而且是不可能的:您已经扩大了输入、输出、标志、条件的组合，并且很难运用所有可能的分支.

Now scale up to 50k, 250k, 1m LOC or more, and LMFAO any time you make a code change. Not only is it unpleasant, it's impossible: you've scaled up the combinations of inputs, outputs, flags, conditions, and it's difficult to exercise all possible branches.

更糟糕的是，LMFAO 可能意味着访问网页应用程序的页面，运行报告，在数十个文件和机器上研究数百万条日志行，阅读生成和发送的电子邮件，检查短信，检查机器人的路径，填写一瓶苏打水，从一百个网络服务中聚合数据，检查金融交易的审计跟踪……你明白了.输出"不是指几行文本，输出"是指聚合系统行为.

Worse, LMFAO might mean visiting pages upon pages of web app, running reports, poring over millions of log lines across dozens of files and machines, reading generated and delivered emails, checking text messages, checking the path of a robot, filling a bottle of soda, aggregating data from a hundred web services, checking the audit trail of a financial transaction... you get the idea. "Output" doesn't mean a few lines of text, "output" means aggregate system behavior.

最后，单元和行为测试定义系统行为.测试可以由持续集成服务器运行并检查正确性.当然，System.outs 也可以，但是 CI 服务器不会知道其中一个是否有错——如果有，它们就是单元测试，你不妨使用一个框架.

Lastly, unit and behavior tests define system behavior. Tests can be run by a continuous integration server and checked for correctness. Sure, so can System.outs, but the CI server isn't going to know if one of them is wrong–and if it does, they're unit tests, and you might as well use a framework.

无论我们认为自己有多好，人类都不是好的单元测试框架或 CI 服务器.

No matter how good we think we are, humans aren't good unit test frameworks or CI servers.

注意:LMAO 正在测试，但在非常的意义上.它不能以任何有意义的方式在整个项目中或作为流程的一部分进行重复.这类似于在 REPL 中进行增量开发，但从未将这些增量测试形式化.

Note: LMAO is testing, but in a very limited sense. It isn't repeatable in any meaningful way across an entire project or as part of a process. It's akin to developing incrementally in a REPL, but never formalizing those incremental tests.

这篇关于为什么要使用 JUnit 进行测试?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！