二、安装JUnit
首先获取JUnit的Y件包Q从http://www.junit.org下蝲最新的软g包?br /> Y件包在适当的目录下解包?br /> q样在安装目录下扑ֈ一个名为junit.jar的文Ӟ这个jar文g加入
CLASSPATHpȝ变量?br />
三、JUnit框架介绍Q?br /> 一QTestCase--试用例Q对每个试c，都要定义一个测试用例?br /> JUnit支持两种q行单个试的方法：静态的和动态的Ҏ?
1、静态的Ҏ是覆盖TestCasecȝrunTest()ҎQ一般是采用内部cȝ方式
创徏一个测试实例：
TestCase test01 = new testCar("test getWheels") {
public void runTest() {
testGetWheels();
}
}
采用静态的Ҏ要注意要l每个测试一个名字，q样你就可以区分哪个试p|
了?
2、动态的Ҏ是用内省来实现runTest()以创Z个测试实例。这要求试的名
字就是需要调用的试Ҏ的名字：
TestCase test01 = new testCar("testGetWheels");
JUnit会动态查扑ƈ调用指定的测试方法。动态的Ҏ很简z，但如果你键入了错
误的名字׃得到一个o人奇怪的NoSuchMethodException异常。动态的Ҏ和静
态的Ҏ都很好，你可以按照自q喜好来选择?br />
二）TestSuite
一旦你创徏了一些测试实例，下一步就是要让他们能一赯行。我们必d义一
个TestSuite。在JUnit中，q就要求你在TestCasecM定义一个静态的suite()?br />
法。suite()Ҏ像main()Ҏ一PJUnit用它来执行测试。在suite()Ҏ?br />
Q你测试实例加C个TestSuite对象中，q返回这个TestSuite对象。一?br />
TestSuite对象可以q行一l测试?br /> TestSuite和TestCase都实CTest接口Q而Test接口定义了运行测试所需的方?br />
。这允怽用TestCase和TestSuite的组合创Z个TestSuite?br /> public static Test suite() {
TestSuite suite= new TestSuite();
suite.addTest(new testCar("testGetWheels"));
suite.addTest(new testCar("testGetSeats"));
return suite;
}
public static Test suite() {
return new TestSuite(testCar.class);
}
三）TestRunner
有了TestSuite我们可以运行这些测试了QJUnit提供了三U界面来q行试
[Text UI] junit.textui.TestRunner
[AWT UI] junit.awtui.TestRunner
[Swing UI] junit.swingui.TestRunner
java junit.textui.TestRunner yourTestclass
Fixture
如果需要在一个或若干个的cL行多个测试，q些cd成ؓ了测试的context。在
JUnit中被UCؓFixture。当你编写测试代码时Q你会发Cp了很多时间配|?
初始化相x试的Fixture。将配置Fixture的代码放入测试类的构造方法中q不
可取Q因为我们要求执行多个测试，我ƈ不希望某个测试的l果意外圎ͼ如果q?br />
是你要求的，那就另当别论了）影响其他试的结果。通常若干个测试会使用?br />
同的FixtureQ而每个测试又各有自己需要改变的地方?
为此QJUnit提供了两个方法，定义在TestCasecM?
protected void setUp() throws java.lang.Exception
protected void tearDown() throws java.lang.Exception
覆盖setUp()ҎQ初始化所有测试的FixtureQ如建立数据库连接，每个测?br />
略有不同的地方在testXXX()Ҏ中进行配|?
覆盖tearDown()Q释放你在setUp()中分配的怹性资源，如数据库q接?
当JUnit执行试Ӟ它在执行每个testXXXXX()Ҏ前都调用setUp()Q而在执行
每个testXXXXX()Ҏ后都调用tearDown()ҎQ由此保证了试不会怺影响?
四）Assert
AssertcM定义了相当多的assertҎQ主要有assert(),assertEquals(),
assertNull(), assertSame(), assertTrue(), fail(){方法?br />
Failep|是一个期望的被assertҎ查到的结果?br /> Error错误则是意外的问题引LQ如ArrayIndexOutOfBoundsException?
四、测试流E：
1. 扩展TestCasec；
2. 覆盖runTest()ҎQ可选）Q?br /> 3. 对应试目标cM写testXXXXX()ҎQ?br /> 4、扩展TestSuitec，重蝲suite()ҎQ实现自定义的测试过E；
5. q行TestRunnerq行试Q?br /> http://www.chinaitlab.com/www/news/article_show.asp?id=24311
]]>
1. 敏捷?#8220;一?#8221;q程
敏捷不是一个过E，是一c过E的l称Q它们有一个共性，是W合敏捷价DQ遵循敏L原则?br />
敏捷的hD如下Q?br />
个体和交?nbsp;胜过 q程和工?br />
可以工作的Y?nbsp;胜过 面面俱到的文?br />
客户合作 胜过 合同谈判
响应变化 胜过 遵@计划
׃hD引出?2条敏捷原则：
我们最优先要做的是通过早的、持l的交付有h值的软g来客户满意?br />
即C开发的后期Q也Ƣ迎改变需求。敏捯E利用变化来为客户创造竞争优ѝ?br />
l常性地交付可以工作的YӞ交付的间隔可以从几个星期到几个月Q交付的旉间隔短好?br />
在整个项目开发期_业务人员和开发h员必d天都在一起工作?br />
围绕被激pv来的个体来构建项目。给他们提供所需的环境和支持Qƈ且信M们能够完成工作?br />
在团队内部，最h效果q且富有效率的传递信息的ҎQ就是面寚w的交谈?br />
工作的Y件是首要的进度度量标准?br />
敏捷q程提倡可持箋的开发速度。责Mh、开发者和用户应该能够保持一个长期的、恒定的开发速度?br />
不断地关注优U的技能和好的设计会增强敏捯力?br />
??使未完成的工作最大化的艺??是根本的?br />
最好的构架、需求和设计于自l织的团队?br />
每隔一定时_团队会在如何才能更有效地工作斚wq行反省Q然后相应地对自q行ؓq行调整?br />
建立敏捷联盟?7位大师所创立的敏h法包括：极限~程QScrumQ特征驱动开发，动态系l开发方法，自适应软g开发，水晶ҎQ实用编E方法。这些方法统UCؓ敏捷Ҏ?br />
其实每个人都可以从敏捷宣a和原则出发，明确问题Q找Z些解x法，形成自己的过E。我觉得国内的Y件环境这么复杂，E序员的自主_又这么强Q敏h法应该是在中国首先提出才对，只是国h都有唯标准唯规范至上的心理定式，即扑և好办法，也觉得不规范Q没有深入Ş成理论，无法提升高度Q始l是跟着鬼子屁股后面赎ͼ我想q也是国外Y件行业不成熟的表C一吧?br />
2. 敏捷仅仅是一个Y件过E?br />
如果仅仅从Y件过E的角度去认识敏捷实施敏P效果不会太好。敏L对以前的软g工程最大的革新之处在于把h的作用提高到了过E至上，正如敏捷宣言的第一?#8220;个体和交互胜q过E和工具”所说的?br />
涉及Ch的问题，已l不再是q程所能覆盖的了，到了企业管理的层面上了Q包括企业的价D和文化。这也是敏捷在国内实施的最大障：
把客户当作合作伙伴而不是对手，从客戯度出发去想问题，充分的跟客户沟通，而不是出了问题推诿责仅R目标是让Y件实现客L价|而不是收钱就完事ѝ?br />
把h的能动性调动v来，l动力而不是给压力?br />
要实用而不是要规范。让开发h员理解ƈ实施Q体验到敏捷的好处，而不是盲目机械地实施规范?br />
没有l对的权威，每个人都有可取之处?br />
3. q代是敏捷QUP属于敏捷?br />
看到q么多h都把UP归入敏捷Q我都开始怀疑是不是自己搞错了。但是在我的印象中：
UP是重型的q程Q虽然引入了q代Q但是其原则和hD与敏h不同的。敏h重的是反馈，q代周期量的短Q重在客L参与Q通过客户的参与，获取持箋的反馈，不断调整使整个项目走在正的方向上。同时也l客户一个感受和思考的ZQ因为对于大多数客户而言Q目标是明确的（不排除有些客L标也不明）Q但是具体怎么做，开始时是没有想法的Q只有看到具体的东西的时候，才知?#8220;噢，原来可以q样Q那我想把这里调整一?#8221;?br />
4. 敏捷是彻底革命的?br />
敏捷Q特别是XPQ让人有耳目一新的感觉Q觉得以前的所有Y件工E理论，设计Ҏ都可以抛弃掉了，推翻一切，从头再来。抱着q种x实施敏捷Q那错了，敏捷不是“矛_里蹦Z孙大?#8221;Q以前的软gq程中也有敏L影子Q只是没有像敏捷一样上升到价D和原则的高度Q比如快速原型法。敏h在对已有的Y件过E方法的改进Q抛弃的是传lY件工E低效的外表Q以往的Y件过E中很多技巧都是很实用的。实施敏捷应该以现有的Y件过Eؓ基础Q从敏捷宣言和原则出发，利用敏捷的方法来改善q程?br />
5. 敏捷是反文档的?br />
文档只是Z达成目标的一U手D，如果q种手段是低效的Q那换一U手Dc可是完全抛弃了文档Q怎样解决沟通的问题Q难道你xơ沟通都完全用手比划Q用嘴说Q跟不同的h重复表述同样的想法，那样更是低效的?br />
应该清楚文档的本质是把知识显性化。在一个项目中存在很多需要沟通的知识Q知识具备两UŞ态，显性的和隐性的Q传l的观念是尽量把隐性知识显性化Q即文档化，而忽略了q其中的代hQ特别是更新同步文档的代P?br />
因此Q在实施敏捷的时候，需要在团队内明哪些知识是必须显性的Q这些知识可以通过文档交流。哪些知识是可以隐性的Q这些知识则完全可以通过口头的方式进行交，以达到沟通的最x率?br />
文档不是目的Q有效沟通才是目的?br />
6. Z敏捷而敏?br />
“嗯，敏捷q么好，我们也敏捷吧”Q可能很多h会有q种x。忘了以前是在哪儿看的大师采访录Q?br />
QQ?#8220;我们现有的过E很好，不知道怎么用敏hq？”
AQ?#8220;既然很好Q那׃要用敏捷”?br />
做什么事情都要有明确目标的，敏捷虽好Q得看你需不需要，能不能解决你现在头疼的问题，如果不是Q那׃要给自己N烦了?br />
7. 敏捷是CMM的反义词
在桂林会议的讨论中，很多人把CMM作ؓ敏捷的反义词Q我觉得q不是很合适。CMM只是一U衡量Y件成熟度的标准，qq程Q和敏捷不是一cLc如果要l敏h一个反义词Q我觉得传统的瀑布式开发应该更合适一些?br />
q且Q我认ؓQ如果CMMq能l箋行下去的话Q应该会有公司可以用敏捷改善的过E通过CMM认证?br />
8. 敏捷是自qQ无U束的?br />
敏捷的是自组l团队，发挥人的能动性，以动力代替压力，让h有绝对自q错觉。但是应该清楚，凡是都是要讲I一个^衡，Z是两面的Q消极的一面和U极的一面同时ƈ存，l对的自׃攄人消极的一面。敏捷ƈ非是l对自由Q无U束的。作为管理者，有一个职责，是引导团队成员用自q极的一面去压制消极的一面，不能放Q团队中出现搭便R的现象，否则打L个团队的士气。如果实在无效，那就只能其排除出团队了Q这个惩|够有约束力吧？
9. 重做是重构
重做不等于重构，很多场合q两个概忉|h的。但是在敏捷中，重构的一个特征是必须可控的。当对系l结构进行大的调整时Q如果没有测试驱动辅助的话，那么可控性就会很差，q不能叫做重构?br />
]]>
许多书上都讨Z自动试Q但是只有很的著作注意到这么一个问题，那就是怎样把这些测试组lv来。随着试的增加，攄和调用这些测试却变得更加ȝ。这成Z个重要问题，以至于出CTDDQ极限编E（XPQTDD得以普及。另外，你可以这L解TDDQ通过试来开发?/font>
TDD的主要规范：
在编写程序代码之前，与之对应的自动测试必被写好。甚至程序代码ƈ不存在，那也要看见一个失败的试l果?/font>
在测试通过后，副本代码必须被丢弃?/font>
有一个具体步骤（可能指的是《Extreme Programming》）可以被Q何一个程序员来参考，而不需要特D的其他Ҏ。在我们开始写试之前Q这些步骤（章节Q应该被首先阅读——怎样l织自动试?/font>
讲解一下不同种cȝ试Q?/font>
单元试Q?/strong>模块（也就是类Q的正确性。如果对象需要访问外部的数据资源Q例如数据库Q就需要模拟一个mock objectsQ但在实际中真实数据与测试环境是不同的?/font>
客户试Q?/strong>q是功能性、系l、和验收试。用来测试整体的pȝҎ。在XP中，q些试qL写?/font>
l合试Q?/strong>介于用户试和单元测试之间的桥梁。综合测试帮助测试应用程序的交互性。一般情况下Qmock objects不被用于l合试Q它会增加测试时间。同Pl合试l常依赖Ҏ的测试环境，例如数据库送来的测试数据。综合测试也需要用到外部类库。例如ؓJ2EE应用E序q行l合试的类库Cactus。解释这些测试超Z本文的范_需要更加详l的信息请参?/font>http://jakarta.apache.org/cactus/?/font>
开发h员测试：q是用来让开发h员检验自׃码或新函数的。对于每一个开发h员，只要有可能，需要有更多的测试来验代码。组l这些测试和l织E序代码一样重要?/font>
在以下章节，只要提到“试”Q那指的是开发h员测试?/font>
我们几乎准备好开始徏立测试了Q先应该为我们的试选择名字。你也许会说Q?#8220;q不是问题：?#8216;Test’q个字放在类名前面，好了！”不会q么快！让我来说一下这个步骤存在的问题Q?/font>
在TDD中，被测试的cL者方法还不存在?/font>
一个测试能够覆盖多个方法，甚至多个c，q是可能的?/font>
以上只是一些普遍问题；q存在更多的问题?/font>
让我来提一个徏议，在测试命名时Q测试类的名字应该让Z眼就知道q是一个测试类Q且能说明它要测试什么，注意是否和其他类重名。按照以上徏议做Q就很简单了Q也不用担心名字太长或难听?/font>
卛_在Eclipse中用JUnit工具创徏我们W一个测试了。假设你已经下蝲了一个最新的Eclipse版本。如果还没有Q你应该d方站点http://www.eclipse.org下蝲。还需要JUnitQ也可以从http://www.junit.org/下蝲?/font>
q行Eclipse。新Z个workplace目Q点?strong>文g->新徏->目Q选择Java目Q点?strong>下一?/strong>。v一个项目名Uͼ例如ProjectWithJUnit。点?strong>完成。这样就完成新项目的建立了。再来配|一下EclipseQ在构徏路径中添加JUnitcd。在工具条上点击目->属?/strong>Q选择Java构徏路径Q?strong>?/strong>Q选择d外部JARQ浏览Junit被存储的目录Q选择junit.jarQ点?strong>打开。你会看见JUnit出现在库的列表中。点?strong>定Q让Eclipse重徏路径?/font>
现在开发我们的“Hello World”例子。按照TDD的规则，应该在代码徏立以前先把测试写好。ؓ了能够在某出开始，我们假设未来的类名是HelloWorldQƈ且有一个方法Say()Q这个方法返回String的|例如“Hello World!”Q?/font>
建立试Q在ProjectWithJUnit的标题上面点d键，选择新徏->其他Q展开“Java”选项Q选择JUnit。在双的栏目对话框中选择试案例Q然后下一步。参考图1?/font>
?. 在Eclipse中徏立JUnit试
在测试类q一栏中Q写上将要被试的类名HelloWorld。选择一?strong>试案例的名字，例如TestThatWeGetHelloWorldPromptQ是的，看上d长，但是很清楚它的行为。）点击完成?/font>
TestThatWeGetHelloWorldPrompt的代码如下：
import junit.framework.TestCase;
public class TestThatWeGetHelloWorldPrompt
extends TestCase {
public TestThatWeGetHelloWorldPrompt(
String name) {
super(name);
}
public void testSay() {
HelloWorld hi = new HelloWorld();
assertEquals("Hello World!", hi.say());
}
public static void main(String[] args) {
junit.textui.TestRunner.run(
TestThatWeGetHelloWorldPrompt.class);
}
}
代码q不复杂Q只是有点与众不同。然而，让我们考察一下细节。我们承了JUnit的TestCasec，它在JUnit的javadocs定义?#8220;q行众多试的夹兗?#8221;JUnit也有TestSuitec，它是一l测试案例的集合Q但在本文中不做讨论?/font>
建立试案例的步骤如下：
1、徏立一个junit.framework.TestCase的实例?/font>
2、定义一些以“test”开头的无返回方法（例如testWasTransactionSuccessful()QtestShow()Q等{）?/font>
TestThatWeGetHelloWorldPrompt.java包含q些QTestCase的子cd一个叫做testSay()的方法。这个方法调用了assertEquals()函数Q它用来比较我们预期的值和由say()q回的倹{?/font>
main()Ҏ用来q行试和显C出的。JUnit的TestRunner处理试Q提供基于图像和文本的输现Ş式。我们用基于文本的版本Q因为Eclipse支持它，且也适合我们。当开始运行后Q基于文本的版本试会以文本形式输出QEclipse会把q些输出自动变成囑փ界面的输出?/font>
按照TDD规范Q首ơ运行测试，应该故意让它p|。点?strong>q行->q行?/strong>->Junit试Q记住TestThatWeGetHelloWorldPrompt.java应该被突出的昄在包资源理器中Q。在左边H口Q应该看见JUnitH口而不?strong>包资源管理器Q它昄一个红条，一ơ失败的试Q具体的p|原因参看?。如果没有自动显C些内容，点击JUnit标签Q在底部的左边）?/font>
?. JUnit中失败的试
很好Q的却失败了。现在我们来建立被测试代码：在包资源理器窗口的ProjectWithJUnit标题上右击，选择新徏->c?/strong>。选择cdQ我们已l假设了它叫HelloWorldQ然后直接点?strong>完成。ؓHelloWorld.java填入下列代码Q?/font>
public class HelloWorld {
public String say() {
return("Hello World!");
}
}
q段代码很简单，甚至不需要注解，我们再来看看l果。按照上面描q过的方式，?strong>JUnit的窗口中昄了一个绿条，参看?。绿条证明测试成功?/font>
?. JUnit中成功的试
现在Q我们想再让试p|一ơ，但原因不同。这有助于展CJUnit试中不同的报错信息。修改assertEquals()代码Q把“Hello World!”变成“Hello Me!”。当再次q行JUnitӞl果变成了红条，?strong>JUnitH口的底部输Zp|原因Q参看图4?/font>
?. JUnit中的ComparisonError
最后，我想说一下关于测试是开发过E中的必要部分的话题。测试代码一直是开发中的重要部分。经q近几年的发展，已得C很大的提高，q要归功于强大的理论研究Q比?#8220;expectations-based development”{等Q，和快速发展的试工具包，q有试q程的改q。如果你对这文章感兴趣Q那请你׃些时间来正式的学习一下测试理论吧Q这对你的工作很有用?/font>
]]>
使用目的
junit是java中书写unit test的frameworkQ目前一些流行的unit test工具大都都是在junit上扩展而来的。目前它的版本是junit3.8.1Q可以从www.junit.org上下载?br />
用法
1. 基本使用步骤QJunit的用非常简单，它的基本使用步骤Q?br />
- 创徏Q从junit.framework.TestCasezunit test需要的test case
- 书写试ҎQ提供类g如下函数{的测试方法：
public void testXXXXX();
- ~译Q书写完test case后，~译所写的test casec?br />
- q行Q启动junit test runnerQ来q行q个test case?br />
Junit提供?个基本的test runnerQ字W界面和囑Ş界面。启动命令分别如下：
a 囑Ş界面Q?br />
java junit.swingui.TestRunner XXXXX
b 字符界面Q?br />
java junit.textui.TestRunner XXXXX
2. 使用例子Q?br />
import junit.frmework.TestCase;
public class TestSample extends TestCaset{
public void testMethod1(){
assertTrue( true);
}
}
3. setUp与tearDownQ这两个函数是junit framework中提供初始化和反初始化每个测试方法的。setUp在每个测试方法调用前被调用，负责初始化测试方法所需要的试环境QtearDown在每个测试方法被调用之后被调用，负责撤销试环境。它们与试Ҏ的关pd以描q如下：
试开?-> setUp -> testXXXX -> tearDown ->试l束
4. 使用例子Q?br />
import junit.frmework.TestCase;
public class TestSample extends TestCaset{
protected void setUp(){
//初始?#8230;…
}
public void testMethod1(){
assertTrue( true);
}
potected void tearDown(){
//撤销初始?#8230;…
}
}
5. 区分fail、exception?br />
- failQ期望出现的错误。生原因：assert函数出错Q如assertFalse(true)Q；fail函数产生Q如fail(……)Q?br />
- exceptionQ不期望出现的错误，属于unit testE序q行时抛出的异常。它和普通代码运行过E中抛出的runtime异常属于一U类型?br />
对于assert、fail{函数请参见junit的javadoc?br />
6. 使用例子Q?br />
import junit.frmework.TestCase;
public class TestSample extends TestCaset{
protected void setUp(){
//初始?#8230;…
}
public void testMethod1(){
……
try{
boolean b= ……
assertTrue( b);
throw new Exception( “This is a test.”);
fail( “Unable point.”); //不可能到?br />
}catch(Exception e){
fail( “Yes, I catch u”); //应该到达?br />
}
……
}
potected void tearDown(){
//撤销初始?#8230;…
}
}
7. l装TestSuiteQ运行更多的test。在junit中，Test、TestCase和TestSuite三者组成了composiste pattern。通过l装自己的TestSuiteQ可以完成对d到这个TestSuite中的所有的TestCase的调用。而且q些定义的TestSuiteq可以组装成更大的TestSuiteQ这样同时也方便了对于不断增加的TestCase的管理和l护?br />
它的另一个好处就是，可以从这个TestCase树的L一个节点（TestSuite或TestCaseQ开始调用，来完成这个节点以下的所有TestCase的调用。提高了unit test的灵zL?br />
8. 使用例子Q?br />
import junit.framework.Test;
import junit.framework.TestSuite;
public class TestAll{
public class TestAll{
//定义一个suiteQ对于junit的作用可以视为类gjava应用E序的main?br />
public static Test suite(){
TestSuite suite = new TestSuite("Running all tests.");
suite.addTestSuite( TestCase1.class);
suite.addTestSuite( TestCase2.class);
return suite;
}
}
q行同运行单独的一个TestCase是一LQ参见step 1 “q行”?br />
9. 使用Ant junit task。我们除了用java来直接运行junit之外Q我们还可以使用junit提供的junit task与antl合来运行。涉及的几个主要的ant task如下Q?br />
- <junit>Q定义一个junit task
- <batchtest>Q位?lt;junit>中，q行多个TestCase
- <test>Q位?lt;junit>中，q行单个TestCase
- <formatter>Q位?lt;junit>中，定义一个测试结果输出格?br />
- <junitreport>Q定义一个junitreport task
- <report>Q位?lt;junitreport>中，输出一个junit report
具体的语法请参见相关文档?br />
10. 使用例子Q?br />
<junit printsummary="yes" haltonfailure="no">
<classpath>
<path refid="classpath"/>
<pathelement location="${dist.junit}"/>
</classpath>
<formatter type="brief" usefile="false"/>
<formatter type="xml"/>
<batchtest todir="${doc.junitReport}">
<fileset dir="${dist.junit}" includes="**/*Test.class" />
</batchtest>
</junit>
<junitreport todir="${doc.junitReport}">
<fileset dir="${doc.junitReport}">
<include name="TEST*-*.xml"/>
</fileset>
<report format="frames" styledir="${junit.styleDir}" todir="${doc.junitReport}"/>
</junitreport>
查表
junit的用ƈ不很难，然而要书写一个好的TestCase却ƈ非易事。一个不好的TestCase往往是既费了时_也v不了实际的作用。相反，一个好的TestCaseQ不仅可以很好的指出代码中存在的问题Q而且也可以作Z码更准确的文档，同时q在持箋集成的过E中起非帔R要的作用。在此给Z写TestCase旉要注意的几点Q?br />
- 试的独立性：一ơ只试一个对象，方便定位出错的位|。这?层意思：一个TestCaseQ只试一个对象；一个TestMethodQ只试q个对象中的一个方法?br />
- l测试方法一个合适的名字?br />
- 在assert函数中给出失败的原因Q如QassertTrue( “… should be true”, ……)Q方便查错。在q个例子中，如果无法通过assertTrueQ那么给出的消息被昄。在junit中每个assert函数都有W一个参数是出错时显C消息的函数原型?br />
- 试所有可能引起失败的地方Q如Q一个类中频J改动的函数。对于那些仅仅只含有getter/setter的类Q如果是由IDEQ如EclipseQ生的Q则可不；如果是h工写Q那么最好测试一下?br />
- 在setUp和tearDown中的代码不应该是与测试方法相关的Q而应该是全局相关的。如针对与测试方法A和BQ在setUp和tearDown中的代码应该是A和B都需要的代码?br />
- 试代码的组l：相同的包Q不同的目录。这P试代码可以讉K被测试类的protected变量/ҎQ方便测试代码的~写。放在不同的目录Q则方便了测试代码的理以及代码的打包和发布。一个例子如下：
src <=源代码根目录
-com-mod1-class1junit <=试代码根目?br />
-com-mod1-class1 ]]>