JUnit主要用来完成什么？

java中框架Junit应该怎么使用？~

JUnit

JUnit是由 Erich Gamma 和 Kent Beck 编写的一个回归测试框架（regression testing framework）。Junit测试是程序员测试，即所谓白盒测试，因为程序员知道被测试的软件如何（How）完成功能和完成什么样（What）的功能。Junit是一套框架，继承TestCase类，就可以用Junit进行自动测试了。
更多JUnit信息

Cactus

Cactus是一个基于JUnit框架的简单测试框架，用来单元测试服务端Java代码。Cactus框架的主要目标是能够单元测试服务端的使用Servlet对象的Java方法如HttpServletRequest,HttpServletResponse,HttpSession等
更多Cactus 信息

Abbot

Abbot是一个用来测试Java GUIs的框架。用简单的基于XML的脚本或者Java代码，你就可以开始一个GUI。
更多Abbot信息

JUnitPerf

Junitperf实际是junit的一个decorator，通过编写用于junitperf的单元测试，我们也可使测试过程自动化。
更多JUnitPerf信息

DbUnit

DbUnit是为数据库驱动的项目提供的一个对JUnit 的扩展，除了提供一些常用功能，它可以将你的数据库置于一个测试轮回之间的状态。
更多DbUnit信息

Mockrunner

Mockrunner用在J2EE环境中进行应用程序的单元测试。它不仅支持Struts actions, servlets，过滤器和标签类还包括一个JDBC和一个JMS测试框架，可以用于测试基于EJB的应用程序。
更多Mockrunner信息

DBMonster

DBMonster是一个用生成随机数据来测试SQL数据库的压力测试工具。
更多DBMonster信息

MockEJB

MockEJB是一个不需要EJB容器就能运行EJB并进行测试的轻量级框架。
更多MockEJB信息

StrutsTestCase

StrutsTestCase 是Junit TestCase类的扩展，提供基于Struts框架的代码测试。StrutsTestCase同时提供Mock 对象方法和Cactus方法用来实际运行Struts ActionServlet，你可以通过运行servlet引擎来测试。因为StrutsTestCase使用ActionServlet控制器来测试你的代码，因此你不仅可以测试Action对象的实现，而且可以测试mappings，from beans以及forwards声明。StrutsTestCase不启动servlet容器来测试struts应用程序（容器外测试）也属于Mock对象测试，但是与EasyMock不同的是，EasyMock是提供了创建Mock对象的API，而StrutsTest则是专门负责测试Struts应用程序的Mock对象测试框架。
更多StrutsTestCase信息

JFCUnit

JFCUnit使得你能够为Java偏移应用程序编写测试例子。它为从用代码打开的窗口上获得句柄提供了支持；为在一个部件层次定位部件提供支持；为在部件中发起事件（例如按一个按钮）以及以线程安全方式处理部件测试提供支持。
更多JFCUnit信息

JTestCase

JTestCase 使用XML文件来组织多测试案例数据，声明条件（操作和期望的结果），提供了一套易于使用的方法来检索XML中的测试案例，按照数据文件的定义来声明结果。
更多JTestCase信息

SQLUnit

SQLUnit是一个单元测试框架，用于对数据库存储过程进行加归测试。用 Java/JUnit/XML开发。
更多SQLUnit信息

JTR

JTR (Java Test Runner)是一个开源的基于反转控制(IOC)的J2EE测试框架。它允许你构建复杂的J2EE测试套件(Test Suites)并连到应用服务器执行测试,可以包括多个测试实例。JTR的licensed是GPL协议。
更多JTR信息

Marathon

Marathon是一个针对使用Java/Swing开发GUI应用程序的测试框架，它由recorder, runner 和 editor组成，测试脚本是python代码。Marathon的焦点是放在最终用户的测试上。
更多Marathon信息

TestNG

TestNG是根据JUnit 和 NUnit思想而构建的一个测试框架，但是TestNG增加了许多新的功能使得它变得更加强大与容易使用比如：
*支持JSR 175注释（JDK 1.4利用JavaDoc注释同样也支持）
*灵活的Test配置
*支持默认的runtime和logging JDK功能
*强大的执行模型（不再TestSuite）
*支持独立的测试方法。
更多TestNG信息

Surrogate Test framework

Surrogate Test framework是一个值得称赞单元测试框架，特别适合于大型，复杂Java系统的单元测试。这个框架能与JUnit,MockEJB和各种支持模拟对象（mock object ）的测试工具无缝给合。这个框架基于AspectJ技术。
更多Surrogate Test framework信息

MockCreator

MockCreator可以为给定的interface或class生成模拟对象（Mock object）的源码。
更多MockCreator信息

jMock

jMock利用mock objects思想来对Java code进行测试。jMock具有以下特点:容易扩展，让你快速简单地定义mock objects,因此不必打破程序间的关联，让你定义灵活的超越对象之间交互作用而带来测试局限，减少你测试地脆弱性。
更多jMock信息

EasyMock

EasyMock为Mock Objects提供接口并在JUnit测试中利用Java的proxy设计模式生成它们的实例。EasyMock最适合于测试驱动开发。
更多EasyMock信息

Grinder

Grinder是一个开源的Java负载测试框架，它通过很多负载注射器来为分布式测试提供了便利。
支持用于执行测试脚本的Jython脚本引擎
HTTP测试可通过HTTP代理进行管理。
更多Grinder信息

XMLUnit

XMLUnit不仅有Java版本的还有.Net版本的。Java开发的XMLUnit提供了两个JUnit 扩展类XMLAssert和XMLTestCase,和一组支持的类。这些类可以用来比较两张XML之间的不同之处，展示XML利用XSLT来,校验XML,求得XPath表达式在XML中的值,遍历XML中的某一节点利DOM展开,
更多XMLUnit信息

Jameleon

Jameleon一个自动化测试工具。它被用来测试各种各样的应用程序，所以它被设计成插件模式。为了使整个测试过程变得简单Jameleon提供了一个GUI,因此Jameleon实现了一个Swing 插件。
更多Jameleon信息

J2MEUnit

J2MEUnit是应用在J2ME应用程序的一个单元测试框架。它基于JUnit.
更多J2MEUnit信息

Jetif

Jetif是一个用纯Java实现的回归测试框架。它为Java程序单元测试以及功能测试提供了一个简单而且可 伸缩的架构，可以用于个人开发或企业级开发的测试。它容易使用，功能强大，而且拥有一些企业级测试的 重要功能。Jetif来源于JUnit, JTestCase以及TestNG的启发，有几个基本的概念直接来自于JUnit， 比如说断言机制，Test Listener的概念，因此从JUnit转到Jetif是非常容易的。
更多Jetif信息

GroboUtils

GroboUtils使得扩展Java测试变得可能。它包括用在Java不同方面测试的多个子项目。在GroboUtils中最常被到的工具是:多线程测试(multi-threaded tests),整体单元测试(hierarchial unit tests),代码覆盖工具(code coverage tool)。
更多GroboUtils信息

Testare

TESTARE是用来简化分布式应用程序(比如:在SERVLETS,JMS listeners, CORBA ORBs或RMI环境下)测试开发过程的一个测试框架.
更多Testare信息

MockLib

MockLib是一个很小的包所以可容易地动态创建一个模拟对象.你可以从模拟的系统中抛出异常来确保你的系统能够正确处理错误.它同样也是一个线程安全的模拟对象库.
更多MockLib信息

JellyUnit

JellyUnit是一个基于Jelly的JUnit测试机制.它允许用Jelly脚本来完成单元测试.尤其是对于XML,XPath,SQL,HTTP,JMS和SOAP交互的测试特别有用.
更多JellyUnit信息

Pisces

这个项目继承于JUnit目的是提供一个分布式的测试环境.它给开发者/测试人员一个运行远程JUnits和复杂测试案例的能力，这个案例由几个并行运行的远程JUnit测试组成。
更多Pisces信息

JUnitEE

JUnitEE是对JUnit的一个简单扩展，可以支持在一个J2EE应用程序服务器上执行标准的测试案例。它主要由一个把测试结果输出为html的servlet组成。
更多JUnitEE信息

测试的概念
长期以来，我所接触的软件开发人员很少有人能在开发的过程中进行测试工作。大部分的项目都是在最终验收的时候编写测试文档。有些项目甚至没有测试文档。现在情况有了改变。我们一直提倡UML、RUP、软件工程、CMM，目的只有一个，提高软件编写的质量。举一个极端的例子：如果你是一个超级程序设计师，一个传奇般的人物。（你可以一边喝咖啡，一边听着音乐，同时编写这操作系统中关于进程调度的模块，而且两天时间内就完成了！）我真得承认，有这样的人。（那个编写UNIX中的vi编辑器的家伙就是这种人。）然而非常遗憾的是这些神仙们并没有留下如何修成正果的README。所以我们这些凡人－－在同一时间只能将注意力集中到若干点（据科学统计，我并不太相信，一般的人只能同时考虑最多7个左右的问题，高手可以达到12个左右），而不能既纵览全局又了解细节－－只能期望于其他的方式来保证我们所编写的软件质量。
为了说明我们这些凡人是如何的笨。有一个聪明人提出了软件熵（software entropy）的概念：一个程序从设计很好的状态开始，随着新的功能不断地加入，程序逐渐地失去了原有的结构，最终变成了一团乱麻。你可能会争辩，在这个例子中，设计很好的状态实际上并不好，如果好的话，就不会发生你所说的情况。是的，看来你变聪明了，可惜你还应该注意到两个问题：1)我们不能指望在恐龙纪元（大概是十年前）设计的结构到了现在也能适用吧。2)拥有签字权的客户代表可不理会加入一个新功能是否会对软件的结构有什么影响，即便有影响也是程序设计人员需要考虑的问题。如果你拒绝加入这个你认为致命的新功能，那么你很可能就失去了你的住房贷款和面包（对中国工程师来说也许是米饭或面条，要看你是南方人还是北方人）。
另外，需要说明的是我看过的一些讲解测试的书都没有我写的这么有人情味（不好意思...）。我希望看到这片文章的兄弟姐妹能很容易地接受测试的概念，并付诸实施。所以有些地方写的有些夸张，欢迎对测试有深入理解的兄弟姐妹能体察民情，并不吝赐教。
好了，我们现在言归正传。要测试，就要明白测试的目的。我认为测试的目的很简单也极具吸引力：写出高质量的软件并解决软件熵这一问题。想象一下，如果你写的软件和Richard Stallman（GNU、FSF的头儿）写的一样有水准的话，是不是很有成就感？如果你一致保持这种高水准，我保证你的薪水也会有所变动。
测试也分类，白箱测试、黑箱测试、单元测试、集成测试、功能测试...。我们先不管有多少分类，如何分类。先看那些对我们有用的分类，关于其他的测试，有兴趣的人可参阅其他资料。白箱测试是指在知道被测试的软件如何（How）完成功能和完成什么样（What）的功能的条件下所作的测试。一般是由开发人员完成。因为开发人员最了解自己编写的软件。本文也是以白箱测试为主。黑箱测试则是指在知道被测试的软件完成什么样（What）的功能的条件下所作的测试。一般是由测试人员完成。黑箱测试不是我们的重点。本文主要集中在单元测试上，单元测试是一种白箱测试。目的是验证一个或若干个类是否按所设计的那样正常工作。集成测试则是验证所有的类是否能互相配合，协同完成特定的任务，目前我们暂不关心它。下面我所提到的测试，除非特别说明，一般都是指单元测试。
需要强调的是：测试是一个持续的过程。也就是说测试贯穿与开发的整个过程中，单元测试尤其适合于迭代增量式（iterative and incremental）的开发过程。Martin Fowler（有点儿像引用孔夫子的话）甚至认为：“在你不知道如何测试代码之前，就不应该编写程序。而一旦你完成了程序，测试代码也应该完成。除非测试成功，你不能认为你编写出了可以工作的程序。”我并不指望所有的开发人员都能有如此高的觉悟，这种层次也不是一蹴而就的。但我们一旦了解测试的目的和好处，自然会坚持在开发过程中引入测试。
因为我们是测试新手，我们也不理会那些复杂的测试原理，先说一说最简单的:测试就是比较预期的结果是否与实际执行的结果一致。如果一致则通过，否则失败。看下面的例子：

//将要被测试的类
public class Car {
public int getWheels() {
return 4;
}
}
//执行测试的类
public class testCar {
public static void main（String[] args) {
testCar myTest = new testCar();
myTest.testGetWheels();
}
public testGetWheels() {
int expectedWheels = 4;
Car myCar = Car();
if (expectedWheels==myCar.getWheels())
System.out.println("test [Car]: getWheels works perfected!");
else
System.out.println("test [Car]: getWheels DOESN'T work!");
}
}
如果你立即动手写了上面的代码，你会发现两个问题，第一，如果你要执行测试的类testCar，你必须必须手工敲入如下命令：
[Windows] d:>java testCar
[Unix] ％ java testCar
即便测试如例示的那样简单，你也有可能不愿在每次测试的时候都敲入上面的命令，而希望在某个集成环境中(IDE)点击一下鼠标就能执行测试。后面的章节会介绍到这些问题。第二，如果没有一定的规范，测试类的编写将会成为另一个需要定义的标准。没有人希望查看别人是如何设计测试类的。如果每个人都有不同的设计测试类的方法，光维护被测试的类就够烦了，谁还顾得上维护测试类？另外有一点我不想提，但是这个问题太明显了，测试类的代码多于被测试的类！这是否意味这双倍的工作？不！1）不论被测试类－Car 的 getWheels 方法如何复杂，测试类－testCar 的testGetWheels 方法只会保持一样的代码量。2）提高软件的质量并解决软件熵这一问题并不是没有代价的。testCar就是代价。
我们目前所能做的就是尽量降低所付出的代价：我们编写的测试代码要能被维护人员容易的读取，我们编写测试代码要有一定的规范。最好IDE工具可以支持这些规范。 好了，你所需要的就是JUnit。一个Open Source的项目。用其主页上的话来说就是：“JUnit是由 Erich Gamma 和 Kent Beck 编写的一个回归测试框架（regression testing work）。用于Java开发人员编写单元测试之用。”所谓框架就是 Erich Gamma 和 Kent Beck 定下了一些条条框框，你编写的测试代码必须遵循这个条条框框：继承某个类，实现某个接口。其实也就是我们前面所说的规范。好在JUnit目前得到了大多数软件工程师的认可。遵循JUnit我们会得到很多的支持。回归测试就是你不断地对所编写的代码进行测试：编写一些，测试一些，调试一些，然后循环这一过程，你会不断地重复先前的测试，哪怕你正编写其他的类，由于软件熵的存在，你可能在编写第五个类的时候发现，第五个类的某个操作会导致第二个类的测试失败。通过回归测试我们抓住了这条大Bug。

回归测试框架-JUnit
通过前面的介绍，我们对JUnit有了一个大概的轮廓。知道了它是干什么的。现在让我们动手改写上面的测试类testCar使其符合Junit的规范－－能在JUnit中运行。
//执行测试的类（JUnit版）
import junit.work.*;
public class testCar extends TestCase {
protected int expectedWheels;
protected Car myCar;
public testCar(String name) {
super(name);
}
protected void setUp() {
expectedWheels = 4;
myCar = new Car();
}
public static Test suite() {
/*
* the type safe way
*
TestSuite suite= new TestSuite();
suite.addTest(
new testCar("Car.getWheels") {
protected void runTest() { testGetWheels(); }
}
);
return suite;
*/
/*
* the dynamic way
*/
return new TestSuite(testCar.class);
}
public void testGetWheels() {
assertEquals(expectedWheels, myCar.getWheels());
}
}
改版后的testCar已经面目全非。先让我们了解这些改动都是什么含义，再看如何执行这个测试。
1>import语句，引入JUnit的类。（没问题吧）
2>继承 TestCase 。可以暂时将一个TestCase看作是对某个类进行测试的方法的集合。详细介绍请参看JUnit资料
3>setUp()设定了进行初始化的任务。我们以后会看到setUp会有特别的用处。
4>testGetWheeels()对预期的值和myCar.getWheels()返回的值进行比较，并打印比较的结果。assertEquals是junit.work.Assert中所定义的方法，junit.work.TestCase继承了junit.work.Assert。
5>suite()是一个很特殊的静态方法。JUnit的TestRunner会调用suite方法来确定有多少个测试可以执行。上面的例子显示了两种方法：静态的方法是构造一个内部类，并利用构造函数给该测试命名(test name, 如 Car.getWheels )，其覆盖的runTest()方法，指明了该测试需要执行那些方法－－testGetWheels()。动态的方法是利用内省（reflection ）来实现runTest()，找出需要执行那些测试。此时测试的名字即是测试方法（test method，如testGetWheels）的名字。JUnit会自动找出并调用该类的测试方法。
6>将TestSuite看作是包裹测试的一个容器。如果将测试比作叶子节点的话，TestSuite就是分支节点。实际上TestCase，TestSuite以及TestSuite组成了一个composite Pattern。 JUnit的文档中有一篇专门讲解如何使用Pattern构造Junit框架。有兴趣的朋友可以查看JUnit资料。
如何运行该测试呢？手工的方法是键入如下命令：
[Windows] d:>java junit.textui.TestRunner testCar
[Unix] ％ java junit.textui.TestRunner testCar
别担心你要敲的字符量，以后在IDE中，只要点几下鼠标就成了。运行结果应该如下所示，表明执行了一个测试，并通过了测试：
.
Time: 0
OK (1 tests)
如果我们将Car.getWheels()中返回的的值修改为3，模拟出错的情形，则会得到如下结果：
.F
Time: 0
There was 1 failure:
1) testGetWheels(testCar)junit.work.AssertionFailedError: expected: but was:
at testCar.testGetWheels(testCar.java:37)
FAILURES!!!
Tests run: 1, Failures: 1, Errors: 0
注意：Time上的小点表示测试个数，如果测试通过则显示OK。否则在小点的后边标上F，表示该测试失败。注意，在模拟出错的测试中，我们会得到详细的测试报告“expected: but was:”，这足以告诉我们问题发生在何处。下面就是你调试，测试，调试，测试...的过程，直至得到期望的结果。

Design by Contract（这句话我没法翻译）
Design by Contract本是Bertrand Meyer（Eiffel语言的创始人）开发的一种设计技术。我发现在JUnit中使用Design by Contract会带来意想不到的效果。Design by Contract的核心是断言（assersion）。断言是一个布尔语句，该语句不能为假，如果为假，则表明出现了一个bug。Design by Contract使用三种断言：前置条件（pre-conditions）、后置条件（post-conditions）和不变式（invariants）这里不打算详细讨论Design by Contract的细节，而是希望其在测试中能发挥其作用。
前置条件在执行测试之前可以用于判断是否允许进入测试，即进入测试的条件。如 expectedWheels > 0, myCar != null。后置条件用于在测试执行后判断测试的结果是否正确。如 expectedWheels==myCar.getWheels()。而不变式在判断交易(Transaction)的一致性（consistency）方面尤为有用。我希望JUnit可以将Design by Contract作为未来版本的一个增强。

Refactoring（这句话我依然没法翻译）
Refactoring本来与测试没有直接的联系，而是与软件熵有关，但既然我们说测试能解决软件熵问题，我们也就必须说出解决之道。（仅仅进行测试只能发现软件熵，Refactoring则可解决软件熵带来的问题。）软件熵引出了一个问题：是否需要重新设计整个软件的结构？理论上应该如此，但现实不允许我们这么做。这或者是由于时间的原因，或者是由于费用的原因。重新设计整个软件的结构会给我们带来短期的痛苦。而不停地给软件打补丁甚至是补丁的补丁则会给我们带来长期的痛苦。（不管怎样，我们总处于水深火热之中）
Refactoring是一个术语，用于描述一种技术，利用这种技术我们可以免于重构整个软件所带来的短期痛苦。当你refactor时，你并不改变程序的功能，而是改变程序内部的结构，使其更易理解和使用。如：该变一个方法的名字，将一个成员变量从一个类移到另一个类，将两个类似方法抽象到父类中。所作的每一个步都很小，然而1－2个小时的Refactoring工作可以使你的程序结构更适合目前的情况。Refactoring有一些规则：
1> 不要在加入新功能的同时refactor已有的代码。在这两者间要有一个清晰的界限。如每天早上1-2个小时的Refactoring，其余时间添加新的功能。
2> 在你开始Refactoring前，和Refactoring后都要保证测试能顺利通过。否则Refactoring没有任何意义。
3> 进行小的Refactoring，大的就不是Refactoring了。如果你打算重构整个软件，就没有必要Refactoring了。
只有在添加新功能和调试bug时才又必要Refactoring。不要等到交付软件的最后关头才Refactoring。那样和打补丁的区别不大。Refactoring 用在回归测试中也能显示其威力。要明白，我不反对打补丁，但要记住打补丁是应该最后使用的必杀绝招。（打补丁也需要很高的技术，详情参看微软网站）

IDE对JUnit的支持
目前支持JUnit的Java IDE 包括 IDE 方式 个人评价（1－5，满分5）
Forte for Java 3.0 Enterprise Edition plug-in 3
JBuilder 6 Enterprise Edition integrated with IDE 4
Visual Age for Java support N/A
在IDE中如何使用JUnit,是非常具体的事情。不同的IDE有不同的使用方法。一旦理解了JUnit的本质，使用起来就十分容易了。所以我们不依赖于具体的IDE，而是集中精力讲述如何利用JUnit编写单元测试代码。心急的人可参看资料。

JUnit是一个Java语言的单元测试框架。它由Kent Beck和Erich Gamma建立，逐渐成为源于Kent Beck的sUnit的xUnit家族中最为成功的一个。 JUnit有它自己的JUnit扩展生态圈。多数Java的开发环境都已经集成了JUnit作为单元测试的工具
另外junit是在极限编程和重构（refactor）中被极力推荐使用的工具，因为在实现自动单元测试的情况下可以大大的提高开发的效率，但是实际上编写测试代码也是需要耗费很多的时间和精力的，那么使用这个东东好处到底在哪里呢？笔者认为是这样的：
极限编程
要求在编写代码之前先写测试，这样可以强制你在写代码之前好好的思考代码（方法）的功能和逻辑，否则编写的代码很不稳定，那么你需要同时维护测试代码和实际代码，这个工作量就会大大增加。因此在极限编程中，基本过程是这样的：构思－> 编写测试代码－> 编写代码－> 测试，而且编写测试和编写代码都是增量式的，写一点测一点，在编写以后的代码中如果发现问题可以较快的追踪到问题的原因，减小回归错误的纠错难度。
重构
其好处和极限编程中是类似的，因为重构也是要求改一点测一点，减少回归错误造成的时间消耗。
其他情况
我们在开发的时候使用junit写一些适当的测试也是有必要的，因为一般我们也是需要编写测试的代码的，可能原来不是使用的junit，如果使用junit，而且针对接口（方法）编写测试代码会减少以后的维护工作，例如以后对方法内部的修改（这个就是相当于重构的工作了）。另外就是因为junit有断言功能，如果测试结果不通过会告诉我们哪个测试不通过，为什么，而如果是像以前的一般做法是写一些测试代码看其输出结果，然后再由自己来判断结果是否正确，使用junit的好处就是这个结果是否正确的判断是它来完成的，我们只需要看看它告诉我们结果是否正确就可以了，在一般情况下会大大提高效率。

JUnit是一个Java语言的单元测试框架。它由Kent Beck和Erich Gamma建立，逐渐成为源于Kent Beck的sUnit的xUnit家族中最为成功的一个。 JUnit有它自己的JUnit扩展生态圈。多数Java的开发环境都已经集成了JUnit作为单元测试的工具。
JUnit是由 Erich Gamma 和 Kent Beck 编写的一个回归测试框架（regression testing framework）。Junit测试是程序员测试，即所谓白盒测试，因为程序员知道被测试的软件如何（How）完成功能和完成什么样（What）的功能。Junit是一套框架，继承TestCase类，就可以用Junit进行自动测试了。
扩展资料：
JUnit是一个开放源代码的Java测试框架，用于编写和运行可重复的测试。他是用于单元测试框架体系xUnit的一个实例（用于java语言）。它包括以下特性：
1、用于测试期望结果的断言（Assertion）
2、用于共享共同测试数据的测试工具
3、用于方便的组织和运行测试的测试套件
4、图形和文本的测试运行器

JUnit是一个Java语言的单元测试框架。它由Kent Beck和Erich Gamma建立，逐渐成为源于Kent Beck的sUnit的xUnit家族中最为成功的一个 JUnit是一个Java语言的单元测试框架。它由Kent Beck和Erich Gamma建立，逐渐成为源于Kent Beck的sUnit的xUnit家族中最为成功的一个

其他情况我们在开发的时候使用junit写一些适当的测试也是有必要的，因为一般我们也是需要编写测试的代码的，可能原来不是使用的junit，如果使用junit，而且针对接口...
搜狗问问小程序

JUnit主要是用来测试白盒的,比方你写了几个函数想想测试它是否执行正常

---

乌海市15917159684： Junit的用处体现在哪儿 - ？
鄢肿开克： JUnit是由 Erich Gamma 和 Kent Beck 编写的一个回归测试框架(regression testing framework).Junit测试是程序员测试,即所谓白盒测试,因为程序员知道被测试的软件如何(How)完成功能和完成什么样(What)的功能.Junit是一套框架,继承TestCase类,就可以用Junit进行自动测试了.

乌海市15917159684： java junit有什么作用呢,普遍用在什么地方呢 - ？
鄢肿开克： Junit, 是Java的单元测试的工具; 如果你看一些软件工程的书籍就会知道, 测试分很多阶段, 第一阶段就是单元测试.Junit作用:Java,我们知道是编程语言,但是任何程序都有可能会出错.为了保证程序如期望的运行和获得结果,进行一些假定条件和假定结果的一种编成思维.小规模的系统看不出效果,一旦有很大规模了.比如涛宝要上一个新的功能,但是涛宝本身有1000万个方法,在每次系统上线的时候, 要确保本身的1000万个方法都是运行正常的, 你怎么办? 如果有junit, 跑一下就知道结果啦.希望对你有帮助.

乌海市15917159684： javajunit有什么用和怎么用? - ？
鄢肿开克： 关于这个问题,junit是用来进行单元测试的. 正规的软件都是要进行详细测试的,junit可以快速的帮助测试,使用方法简单. 一般eclipse都有自带,当然,没有的话也可以去下载这个插件.使用方法很简单,引入junit到工程后,加上一些控制命令,例如执行多少次等等就可以了.具体你可以到网上搜一下,很多的.

乌海市15917159684： 什么是junit测试程序?？
鄢肿开克： JUnit是一个开发源代码的Java测试框架,用于编写和运行可重复的测试.他是用于单元测试框架体系xUnit的一个实例(用于java语言).它包括以下特性: 1、用于测试期望结果的断言(Assertion) 2、用于共享共同测试数据的测试工具 3、用...

乌海市15917159684： android - junit - report这个工具怎么用 - ？
鄢肿开克： Android增加了对JUnit的支持,这对程序员来说,是个很好消息.首先说明下JUnit是用来解决什么问题的?JUnit是采用测试驱动开发的方式,也就是说在开发前先写好测试代码,主要用来说明被测试的代码会被如何使用,错误处理等;然后开始写代码,并在测试代码中逐步测试这些代码,直到最后在测试代码中完全通过.先有测试规范,然后才有高质量的代码.软件测试的先进思想在将来的企业真实项目开发中,必然会越来越受到重视和推广. 明白了junit的作用 ,所以 这个report的工具应该就是报告工具了.

乌海市15917159684： junit和loadrunner分别是测试什么的? - ？
鄢肿开克： 你好.Junit是做单元测试的. loadrunner是一种适用于各种体系架构的自动负载测试工具,它能预测系统行为并优化系统性能.一般用作压力测试.详细的你可以百度百科一下.

乌海市15917159684： 面试问题:JUNIT架构是什么? - ？
鄢肿开克： 楼上正解是一个主要用来做单元测试的框架

乌海市15917159684： 请问下,JUnit单元测试有什么用?? - ？
鄢肿开克： 你自己测试只是意思一下而已,不够正规用JUnit测试会有测试案例和测试结果,方便给领导汇报工作作为依据而且听说有的公司先写测试案例,后实现功能,这种情况下就必须要用了 查看原帖>> 希望采纳

乌海市15917159684： 菜鸟Java单元测试 - ？
鄢肿开克： 这几天看到,有好多同学上来求怎样学习java.看到后实在很想给他们回帖,可是这又不是2句话能说清的, 其中牵扯到,用什么样的书,怎样学,哪些要学. 在这我把我的学习方法写出来,希望能对初学的 有用. 其实本人也是菜鸟一个.若有什么...

乌海市15917159684： 目前最常用的Java开发工具有哪些 - ？
鄢肿开克： 常用的工具有:Eclipse 据数据显示很多Java开发人员的Java开发工具便是Eclipse,这主要得益于Eclipse是一个开源的、可以基于Java的可扩展开发平台.Eclipse本身而言,它只是一个框架和一组服务,但可以通过插件组件构建开发环境....