JUnit设计模式分析与JUnit应用.pptVIP

Adapter模式 对象的适配器 Adapter模式 在实现对象的适配时，首先在TestCase中定义测试方法的命名规则必须是public void testXXXXX()。 如果符合规则认为是测试方法，然后使用Adapter模式把这些方法，适配成Command的runTest()方法。在实现时使用了java的反射技术，这样便可很容易实现动态适配。 使用Adapter模式简化测试用例的开发，通过按照方法命名的规范来开发测试用例，不需要进行大量的类继承，提高代码的复用，减轻测试人员的工作量。 使用Adapter可以重新定义Adaptee的部分行为，如增强异常处理等。 Observer模式 失败（failures）和错误（errors）： 失败是可预期的，并且可以使用断言（assertion）来进行检查。 错误是不可预期的，如数组越界。 Observer模式 JUnit必须报告测试的进行状况，如打印到控制台、GUI界面，甚至同时需要输出到多种介质。 JUnit提供了三种方式：textui、swingui、awtui，当TestCase的执行有错误或者失败时，所有依赖这些状态的对象必须自动更新。 JUnit不希望为了维护一致性而使各个类紧密耦合，因为这样会降低它们的重用性，如何解决这个问题？ Observer模式 Observer模式 Observer就是TestListener，它是一个接口，定义了几个方法，由具体的类实现。 JUnit里有三种方式来实现TestListener。 例：TextUi方式由一个类ResultPrinter实现。 使用TestResult来收集测试的结果，它使用Collecting Parameter设计模式，它实际是ConcreteSubject，在JUnit中Subject和ConcreteSubject是同一个类。 Observer模式 Subject和Observer之间地抽象耦合，一个TestResult所知道的仅仅是它有一系列的观察者，每个观察者都实现TestListener接口，TestResult不必知道任何观察者属于哪一个具体的实现类，这样使TestResult和观察者之间的耦合是抽象的和最小的。 支持广播通信，被观察者TestResult会向所有的登记过的观察者如ResultPrinter发出通知。这样不像通常的请求，通知的发送不需指定它的接收者，目标对象并不关心到底有多少对象对自己感兴趣，它唯一的职责就是通知它的观察者。 Decorator模式 TestCase是一个及其重要的类，它定义了测试步骤和测试的处理。但是作为一个框架，应该提供很方便的方式进行扩展，允许不同的开发人员开发适合自己的TestCase。 使用继承机制是增加功能的一种有效途径，例如RepeatedTest继承TestCase实现多次测试用例，测试人员然后继承RepeatedTest来实现。 继承机制不够灵活，每增一种功能就必须继承，使子类数目呈爆炸式的增长，开发人员不能动态的控制对功能增加的方式和时机。JUnit必须采用一种合理，动态的方式进行扩展。 Decorator模式 Decorator模式 Test接口是Component抽象构件角色。 TestCase是ConcreteComponent具体构件角色。 为了增加Decorator角色，需要开发一个TestDecorator类。它实现Test接口，并且有一个私有的属性Test fTest，接口的实现都委托给fTest的run，该方法将由ConcreteComponent具体的装饰类来实现，以增强功能。 具体的装饰类RepeatedTest，它可以多次执行一个TestCase，增强了TestCase的功能。 动态的为TestCase增加功能：首先使用一个具体的TestCase，然后通过RepeatedTest给这个TestCase增加功能，可以进行多次测试。 Decorator模式 实现了比静态继承更加灵活的方式，动态的增加功能。 避免在层次结构中的高层的类有太多的特征属性。Decorator模式不使用类的多层次继承来实现功能的累积，而是从简单的TestCase组合出复杂的功能。 JUnit最佳实践 不要用TestCase的构造函数初始化Fixture，而要用setUp()和tearDown()方法。? 不要依赖或假定测试运行的顺序，因为JUnit利用Vector保存测试方法。所以不同的平台会按不同的顺序从Vector中取出测试方法。? 避免编写有副作用的TestCase。例如：如果随后的测试依赖于某些特定的交易数据，就不要提交交易数据。简单的回滚就可以了。? 当继承一个测试类时，记得调用父类的setUp()和t