为什么要使用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?

无论是编写简单的应用程序还是更大的应用程序，我都使用系统测试它们.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 一次测试它，但不能创建Test-classes？

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

PS。我从未参与过刚学习的大型项目。

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.out 也可以，但是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: As pointed out (rudely) in the comments, 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屋！