虽然在物理上,业务类和测试用例类被放在不同目录下,但在工程窗格的资源树中,业务类和测试用例还是挤在了一起。如果一个包下有多个业务类,加上它们相应的测试用例类,将显得更加拥挤不堪。所以最好将测试用例放到不同的包中,如com.super.bdbj包中的所有业务类的测试用例放到test.super.bdbj目录下,这样将彻底解决测试用例和业务类的物理和逻辑上的分离,使工程窗格中的资源树更加整洁明了。
TestSubsection类的代码如下所示:
代码清单 错误!文档中没有指定样式的文字。向导生成的TestSubsection类
1. package chapter25; 2. 3. import junit.framework.*; 4. public class TestSubsection extends TestCase { 5. private Subsection subsection = null; 6. protected void setUp() throws Exception { 7. super.setUp(); 8. subsection = new Subsection(); 9. } 10. 11. protected void tearDown() throws Exception { 12. subsection = null; 13. super.tearDown(); 14. } 15. 16. public void testGetValue() { 17. int d = 0; 18. int expectedReturn = 0; 19. int actualReturn = subsection.getValue(d); 20. assertEquals("return value", expectedReturn, actualReturn); 21. /**@todo fill in the test code*/ 22. } 23. 24. public void testSign() { 25. double d = 0.0; 26. int expectedReturn = 0; 27. int actualReturn = subsection.sign(d); 28. assertEquals("return value", expectedReturn, actualReturn); 29. /**@todo fill in the test code*/ 30. } 31. } |
在第5行声明了一个Subsection的成员变量,并在setUp()中实例化这个变量(第7行),在tearDown()中释放这个变量(第12行),其实这三部分就构成了一个测试固件。当然,由于我们的getValue()、sign()方法都是静态方法,所以并不需要这个固件,在测试方法中直接调用方法就可以了,如Subsection.getValue(),但为了加强概念上的认识,我们特别予以保留。
第16~22行的testGeValue()方法,和第24~30行的testSign(),就是在向导第1步所选择的需要测试的API方法对应的测试方法。JBuilder当然不可能知道我们API的逻辑规则,所以它仅提供了一个框架式的测试代码,需要我们发挥聪明才智通过assertXxx()定制覆盖性强的测试规则。
注意:
你也可以手工在TestSubsection类中添加测试方法,测试方法必须遵照public void testXxx()样式规范。所以如果你想在测试用例类中添加一个辅助性的方法,请不要以test为前缀,在更改业已生成的测试方法名称时,也要保证不去除方法前的test前缀,测试运行器籍此查找测试用例类中的测试方法。
文章来源于领测软件测试网 https://www.ltesting.net/