昨天，刚刚下载下来，小试了一下。决得是不错。
但是如果用，全凭程序员自己的爱好和认识。
如果要在开发中形成规范，那是项目主管、强制的问题。
存在的问题，开发的时候，没有任何单元测试经验，我想会效率低、很慢。
好处可以保证最底层，最基本程序单元的正确性，能够及早的捕获bug，为以后软件的部件的重用和集成测试都是有很大帮助。。总之，及早的发现问题is good。
但是如果用，全凭程序员自己的爱好和认识。
如果要在开发中形成规范，那是项目主管、强制的问题。
存在的问题，开发的时候，没有任何单元测试经验，我想会效率低、很慢。
好处可以保证最底层，最基本程序单元的正确性，能够及早的捕获bug，为以后软件的部件的重用和集成测试都是有很大帮助。。总之，及早的发现问题is good。
using !
马上要单元测试了！
这个软件在执行测试，错误检测方面提供了一些简单方法和接口，
但是大部分测试代码都需要自己手工写。不过静下心来写一个的
测试后，对以后的修改调试帮助很大，节省了许多重复的手工劳动。
做软件还是要老老实实的，这样也保证了软件的可控性。相关名词：Junit 持续集成 日志管理
如果是其他的开发环境，可以到 www.junit.org 下载
还有其他的工具，但都是基于各种开发语言的
有机会访问我的网站 www.oodiscovery.com
不过，创建测试案例可也不是个简单的过程，当事人得清楚地知道代码的有关情况及其运做机理。你必须小心创建Junit执行的单元测试，保证测试能像在真实环境下运行那样严格地检查代码。本文首先讨论如何创建单元测试，然后阐述各个测试部分如何组合起来。创建测试案例Junit的测试案例由扩展Junit框架的Java类编写。这些类拥有大量的方法，每一种方法测试特定的功能或者说代码单元（unit）。比方说，对简单财务管理软件来说，测试就可能包括用户名和密码的登录过程。其次则可能要检查存款余额、保证资产节余的正确性。第3个测试可能涉及到模拟从帐户中取钱的过程。通常，你编写的测试案例越多，测试的完整性也就最好。你应当测试产品的全部功能领域：只有这样做才能保证系统的局部变动不至于影响到系统的其他部分。创建新的测试案例很容易。正如你在清单A中看到的那样，编写新的测试案例需要创建新的Java类。新类必须扩展TestCase类，同时包含一个构造器调用基类的构造器。新类叫做test harness，这就是你编写自己测试程序的场所。每次调用测试的时候，Junit就会执行setUp()方法初始化你需要的任何值。接着，它会调用一个测试案例然后再调用tearDown() 取消初始化并进到下一个测试。这个简单的测试工作由两个测试组成，testBooleanTrue()和testBooleanFalse()。每一个测试都必须公开声明而且必须调用Junit通知测试状态。在这种情况下，我们令某一个测试总是成功而另一个则总是失败。
示例现在就让我们详细地讨论一个测试案例。在我们的例子里，我们将对Xerces XML解析器进行测试，该解析器可以从Apache XML项目免费获取。我们还测试一个简单的XML文档，如清单B所示。我们的测试案例如清单C所示。XMLTest.java测试案例包含两个测试。第1个是testPersonCount()，它查看XML文档中列出的人员数是否在0和10之间。如果是测试案例就给assertTrue()方法返回true，测试就算成功了。可是，如果项目太少或者太多那么测试就会失败。另一个测试保证人员“James Scheinblum”也包含在文件之内。我们通过编辑Example.xml文档的方式尝试了这两个测试。测试案例采用了setUp() 和 tearDown() 方法来保证每一次测试都会重载XML文档。假如扔出了异常，比如混乱的XML文档或者不能打开文档阅读等等，测试会调用失败的方法，经过它告诉Junit测试失败，而失败结果则被传递给assertTrue()。两种不同的断言都在JavaDocs for Junit中文档化了，详细内容请看这里。既然已经创建了我们自己的测试，接下来就该运行测试了。为此还得首先创建一个测试包。
创建测试包所谓测试包（test suite）其实就是同一会话中应当执行的测试集合。测试包把测试组织在一起执行，而不论测试是否在同一文件里。清单D显示我们的测试包其实就是清单C中的那两个测试。在执行这些测试的时候我们要用到下一节中介绍的方法定义。
运行哪个测试？在我们的测试包里我们明确定义了要运行的测试。那就是说当我们编写更多测试的时候需要把它们加到测试包里来。显式定义要运行的测试就等于定义了它们运行的次序。当然，你也可以用reflection自动地发现测试案例。这意味着你只需要针对每次测试执行编写一次测试包，它动态地确定哪些测试可用并且运行这些测试。但其缺点却是你无法排斥测试的运行，而且你无法控制测试被执行的顺序。不过，由于没有向测试包中加入测试案例，所以reflection确实能保证你在创建测试案例的过程中没有遗留任何一步。清单E 显示如何把类的名字传递给测试包构造器来自动装载测试。现在我们就拿这个测试包进行测试。
运行Junit测试执行测试需要创建可执行类来调用Junit测试运行器。运行器（runner）负责执行测试包，运行所有的测试并输出测试结果。清单F显示如何把测试包集成到测试运行器中。正如你所看到的那样，测试运行器并不关心测试包是否明确定义了要运行的测试案例或者测试包是否采用了reflection来确定测试的名称。如果一切OK，Junit就象清单G那样输出结果。但是要出了什么问题的话输出的结果就可能如清单H那样。用Junit创建测试案例很简单，而且还有助于把软件开发过程中的错误最小化。要了解这方面的更多信息请参看JUnit.org。