Manning. JUnit in Action 文摘-1
2008-03-21 15:11
323 查看
Chapter 2:
Most developers now rely on the automatic TestSuite and rarely create manual suites.
TestResult stores the details of all your tests, pass or fail. The TestCalculator program (listing 2.1) includes a line that says assertEquals(60, result, 0); If the result did not equal 60, JUnit would create a TestFailure object to be stored in the TestResult. The TestRunner uses the TestResult to report the outcome of your tests. If there are no TestFailures in the TestResult collection, then the code is clean, and the bar turns green. If there are failures, the TestRunner reports the failure count and the stack trace for failing tests.
JUnit distinguishes between failures and errors. Failures are to be expected. From time to time changes in the code will cause an assertion to fail. When it does, you fix the code so the failure goes away. An error is an unexpected condition that is not expected by the test, such as an exception in a conventional program.
As a JUnit test writer, you won’t interact with the TestResult directly; but in trying to understand how JUnit works, it’s helpful to know that it exists.
“When you need to collect results over several methods, you should add a parameter to the method and pass an object that will collect the results for you.” The TestResult class is an example of the Collecting Parameter pattern.
The JUnit framework provides the TestListener interface to help objects access the TestResult and create useful reports. The TestRunners implement TestListener, as do many of the special JUnit extensions.
although the TestListener interface is an interesting bit of plumbing, you would only need to implement it if you were extending the JUnit framework, rather than just using it.
The set of background resources that you need to run a test is commonly called a test fixture.
A key reason why you put more than one test method into the same TestCase is to share the fixture code.
You can also use a fixture to generate input files; doing this means you do not have to carry your test files with your tests
Each unit test must run independently of all other unit tests.
Most developers now rely on the automatic TestSuite and rarely create manual suites.
TestResult stores the details of all your tests, pass or fail. The TestCalculator program (listing 2.1) includes a line that says assertEquals(60, result, 0); If the result did not equal 60, JUnit would create a TestFailure object to be stored in the TestResult. The TestRunner uses the TestResult to report the outcome of your tests. If there are no TestFailures in the TestResult collection, then the code is clean, and the bar turns green. If there are failures, the TestRunner reports the failure count and the stack trace for failing tests.
JUnit distinguishes between failures and errors. Failures are to be expected. From time to time changes in the code will cause an assertion to fail. When it does, you fix the code so the failure goes away. An error is an unexpected condition that is not expected by the test, such as an exception in a conventional program.
As a JUnit test writer, you won’t interact with the TestResult directly; but in trying to understand how JUnit works, it’s helpful to know that it exists.
“When you need to collect results over several methods, you should add a parameter to the method and pass an object that will collect the results for you.” The TestResult class is an example of the Collecting Parameter pattern.
The JUnit framework provides the TestListener interface to help objects access the TestResult and create useful reports. The TestRunners implement TestListener, as do many of the special JUnit extensions.
although the TestListener interface is an interesting bit of plumbing, you would only need to implement it if you were extending the JUnit framework, rather than just using it.
The set of background resources that you need to run a test is commonly called a test fixture.
A key reason why you put more than one test method into the same TestCase is to share the fixture code.
You can also use a fixture to generate input files; doing this means you do not have to carry your test files with your tests
Each unit test must run independently of all other unit tests.
相关文章推荐
- ActionScript 3.0 编程体验
- 什么是DAO Database Access Object
- Ajax in action 英文版配书源码 下载
- javascript object oriented 面向对象编程初步
- Using the TextRange Object
- JAVA的Interface观念与C++多重继承的比较
- 淺談Interface
- 归纳Java中的Interface(接口)
- AS3.0教程(1):与Flash9先来一次亲密接触!
- 第一次用,看看效果如何!
- java3d异常
- ATL实现Connection Point的一种简单的方法
- 微软专利技术“茶壶用户界面”--可能对 Windows 7 的用户体验有重要影响
- 学习笔记---使用prototype.js扩展struts标签实现xmlhttprequest
- javascript表单之间的数据传递!
- JBuilder2005无法启动的奇怪问题!
- Java测试规范(引用)
- 测试Blog
- [Oracle Transaction]Oracle数据库事务
- [Oracle PL SQL]PL/SQL块书写