public class String Test extends Test Case protected

一个完整的测试用例 public class String. Test extends Test. Case { protected void set. Up(){ /* run before */} protected void tear. Down(){ /* after */ } public void test. Simple. Equal() { String s 1 = new String(“abcd”); String s 2 = new String(“abcd”); assert. True(“Strings not equal”, s 1. equals(s 2)); } } public static void main(String[] args){ junit. textui. Test. Runner. run (suite ()); }

l HEHE

Course Sample public class Student. Test extends Test. Case { public void test. Take. Course() { Course. Evaluation. Factory system = Course. Evaluation. Factory. get. Instance(); ICourse course = factory. create. Course("OOT", "面向�象技�"); IStudent student = factory. create. Student("001", "test"); int size = course. get. Students(). size(); student. take. Course(course); assert. Equals(size+1, course. get. Students(). size()); } }

Course Sample public void test. Course. Not. Avaliable() { Course. Evaluation. Factory factory = Course. Evaluation. Factory. get. Instance(); ICourse course = factory. create. Course("OOT", "面向�象技�"); try { int i=0; for (; i < course. get. Allow. Students(); i++) { IStudent student = factory. create. Student(i, "test"); student. take. Course(course); } IStudent student = factory. create. Student(i+1"test"); student. take. Course(course); fail("Course. Not. Available. Exception expected"); } catch (Course. Not. Available. Exception e) {} }

Test. Runners l 基于文本 l l 轻量级，快速 从命令行启动 java String. Test. . . . Time: 0. 05 Tests run: 7, Failures: 0, Errors: 0

Test. Runners - Swing l 图形界面，通过启动 java junit. swingui. Test. Runner

Test. Runner : Eclipse IDE

Test. Runnit: . NET平台下的NUnit

Designing for testing l To test a component, you must be able to control its input (and internal state) and observe its output. If you cannot control the input, you cannot be sure what has caused a given output. If you cannot observe the output of a component under test, you cannot be sure how a given input has been processed

Design for testing l Separation of interface and implementation l l Allows substitution of implementation to tests Factory pattern(Or use Io. C Container) l Provides for abstraction of creation of implementations from the tests.

Design for testing - Mock Objects l When your implementation requires a resource which is unavailable for testing l l External system or database is simulated. Another use of Factory, the mock implementation stubs out and returns the anticipated results from a request.

Introducing mock objects l Definition l l A mock object is an object created to stand in for an object that your code will be collaborating with. Your code can call methods on the mock object, which will deliver results as set up by your tests. Mock objects are perfectly suited for testing a portion of code logic in isolation from the rest of the code. Mocks replace the objects with which your methods under test collaborate, thus offering a layer of isolation.

Mock tasting: a simple example l Make a bank transfer from one account to another

Class under test

Account. Manager as Interface

Mock. Account. Manager

Test Case for Account. Service

Using mock objects as a refactoring technique l What’s wrong with the following code:

Using mock objects as a refactoring technique l Easy refactoring

Using mock objects as a refactoring technique l Easy refactoring

Design patterns in action l Inversion of Control(Io. C) l Applying the Io. C pattern to a class means removing the creation of all object instances for which this class is not directly responsible and passing any needed instances instead.

Using mock objects as a refactoring technique l l l Some people used to say that unit tests should be totally transparant to your code under test, and that you should not change runtime code in order to simplify testing. This is wrong. Unit tests are first-class users of the runtime code and deserve the same consideration as any other user.

Pros and cons of mock objects l l The biggest advantage of the mock-object approach is that it does not require a running container in order to execute the tests The drawbacks of using mock objects are: l l l Do not test interactions with the container or between the components Do not test the deployment part of the components Need excellent knowledge of the API being called in order to mock it, which can be difficult

重构的例子 public boolean is. Leep. Year 1(int year) { return (year % 400) == 0 || ((year % 4 == 0) && (year % 100 != 0)); } public boolean is. Leep. Year 2(int year) { boolean is. Forth. Year = (year % 4 == 0); boolean is. Hundreth. Year = (year % 100 == 0); boolean is 4 Hundreth. Year = ((year % 400) == 0); return is 4 Hundreth. Year || (is. Forth. Year && !is. Hundreth. Year); }