Junit Architecture LiuBing [email protected]. Agenda Junit Background Usage Junit Junit architecture...

51
Junit Architecture LiuBing [email protected]

Transcript of Junit Architecture LiuBing [email protected]. Agenda Junit Background Usage Junit Junit architecture...

Junit Architecture

LiuBing [email protected]

Agenda Junit Background Usage Junit Junit architecture and design

pattrens Conclusion

Junit JUnit is an open source Java testing framework used to write and

run repeatable tests. It is an instance of the xUnit architecture for unit testing frameworks.

JUnit features include:

* Assertions for testing expected results

* Test fixtures for sharing common test data

* Test suites for easily organizing and running tests

* Graphical and textual test runners

JUnit was originally written by Erich Gamma and Kent Beck.

Martin Fowler

Never in the field of software development was so much owed by so many to so few lines of code" Martin Fowler

Martin Fowler 在面向对象分析设计、 UML 、模式、软件开发方法学、 XP 、重构 ... 方面,都是世界顶级的专家,现为 ThoughtWorks 首席科学家。 Martin Fowler 著有 4 本经典书籍:“ Analysis Patterns : Reusable Object Models” “、 UML Distilled: Applying the Standard Object Modeling Language” “、 Refactoring: Improving the Design of Existing Code” “、 Planning Extreme Programming” 。

JavaWorld * 2002 JavaWorld Editors' Choice Awards

(ECA) Best Java Performance Monitoring/Testing

Tool * 2001 JavaWorld Editors' Choice Awards

(ECA) Best Java Performance Monitoring/Testing

Tool

Developer-Kent Beck Kent Beck

Kent Beck 先生是软件开发方法学的泰斗,是XP ( Extreme Programming )的创始人,有 17 年的面向对象的编程经验。 他倡导软件开发的模式定义, CRC 卡片在软件开发过程中的使用, HotDraw 软件的体系结构,基于 xUnit 的测试框架,重新评估了在软件开发过程中测试优先的编程模式。 Kent Beck 是《 The Smalltalk Best Practice Patterns 》、《 Extreme Programming Explained 》和《 Planning Extreme Programming (与 Martin Fowler 合著)》的作者,并且承担了 XP 的领导工作。 他现在是 Three Rivers Institute 的总裁。 TRI 从事于技术和商业接合的应用研究,是是新近成立的Agile Alliance 的创始成员, Agile Alliance 的使命就是要创建更好的软件开发方法。

Developer- Erich Gamma

Erich Gamma is the Technical Director of the Software Technology Center of ObjectTechnologyInternational (OTI) in Zurich.

Some of his recent projects are: EclipseIde - IBM's new platform for development tools JFace - the Eclipse UI Framework Eclipse Java Tooling IBM VisualAge MicroEdition? IDE ULC - Ultra Light Client an infrastructure for thin Java clients.

Erich pairs as often as possible with KentBeck to work on JavaUnit.

He's author number 1 of the GangOfFour and feels more and more guilty that there isn't a 2nd edition...

XP Extreme Programming is a discipline of software

development based on values of simplicity, communication, feedback, and courage. It works by bringing the whole team together in the presence of simple practices, with enough feedback to enable the team to see where they are and to tune the practices to their unique situation.

Usage Junit

JUnit Infected: Programmers Love Writing Tests

see Test Infected: Programmers Love Writing Tests, Java Report, July 1998, Volume 3, Number 7

IDE JBuilder Eclipse Forte/Netbeans IntelliJ TogetherJ Visual Age JDeveloper Integration

JB7

test

public class test { public int add(int a,int b){ return a+b; }}

TestCase

public class Testtest extends TestCase { public Testtest(String s) { super(s); } protected void setUp() { System.out.println("setUp"); } protected void tearDown() { System.out.println("tearDown"); } public void testAdd() { test test = new test(); this.assertEquals(12,test.add(9, 1)); }}

Junit Result

Junit Architecture & Patterns

Goals What are the goals of JUnit?

Junit Architecture -Microkernel

Microkernel

extensi ons

FrameWork

Patterns Generate Architectures

The design of JUnit will be presented in a style first used in (see "Patterns Generate Architectures", Kent Beck and Ralph Johnson, ECOOP 94). The idea is to explain the design of a system by starting with nothing and applying patterns, one after another, until you have the architecture of the system. We will present the architectural problem to be solved, summarize the pattern that solves it, and then show how the pattern was applied to JUnit

Patterns

Getting started- TestCase

Test

countTestCases() : intrun(result : junit.framework.TestResult) : void

Encapsulate a request as an object, thereby letting you… queue or log requests…" Command tells us to create an object for an operation and give it a method "execute".

TestCase

Test

countTestCases() : intrun(result : junit.framework.TestResult) : void

TestCase

fName : String

TestCase()TestCase(name : String)countTestCases() : intcreateResult() : junit.framework.TestResultname() : Stringrun() : junit.framework.TestResultrun(result : junit.framework.TestResult) : voidrunBare() : voidrunTest() : voidsetUp() : voidtearDown() : voidtoString() : StringgetName() : StringsetName(name : String) : void

Blanks to fill in- run()

Define the skeleton of an algorithm in an operation, deferring some steps to subclasses. Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm’s structure

TestCaseHere is the template method: public void run() {

    setUp();     runTest();     tearDown(); }

The default implementations of these methods do nothing: protected void runTest() {

} protected void setUp() {

} protected void tearDown() {

}Since setUp and tearDown are intended to be overridden but will

be called by the framework we declare them as protected

SubClass TestCasepublic class Testtest extends TestCase { public Testtest(String s) { super(s); } protected void setUp() { System.out.println("setUp"); } protected void tearDown() { System.out.println("tearDown"); } public void testAdd() { test test = new test(); this.assertEquals(12,test.add(9, 1)); }}

Don’t care about one or many - TestSuite

Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly

TestSuitepublic class TestSuite implements Test { private Vector fTests= new Vector(10); public void addTest(Test test) {

fTests.addElement(test); } public void run(TestResult result) {

for (Enumeration e= tests(); e.hasMoreElements(); ) { if (result.shouldStop() ) break;

Test test= (Test)e.nextElement();runTest(test, result);

} }}

JB TestSuit

Reporting results- TestResult

Collecting Parameter suggests that 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.

TestResultTestResult

fFailures : java.util.VectorfErrors : java.util.VectorfListeners : java.util.VectorfRunTests : intfStop : boolean

TestResult()addError(test : junit.framework.Test, t : java.lang.Throwable) : voidaddFailure(test : junit.framework.Test, t : junit.framework.AssertionFailedError) : voidaddListener(listener : junit.framework.TestListener) : voidremoveListener(listener : junit.framework.TestListener) : voidcloneListeners() : java.util.VectorendTest(test : junit.framework.Test) : voiderrorCount() : interrors() : java.util.EnumerationfailureCount() : intfailures() : java.util.Enumerationrun(test : final junit.framework.TestCase) : voidrunCount() : intrunProtected(test : final junit.framework.Test, p : junit.framework.Protectable) : voidrunTests() : intshouldStop() : booleanstartTest(test : junit.framework.Test) : voidstop() : voidtestErrors() : inttestFailures() : intwasSuccessful() : boolean

TestCase Runpublic void run(TestResult result) {

    result.startTest(this);     setUp();     try {         runTest();     }     catch (AssertionFailedError e) { //1         result.addFailure(this, e);     }     catch (Throwable e) { // 2         result.addError(this, e);     }     finally {         tearDown();     } }

Extend TestResult

JUnit comes with different implementations of TestResult. The default implementation counts the number of failures and errors and collects the results. TextTestResult collects the results and presents them in a textual form. Finally, UITestResult is used by the graphical version of the JUnit Test Runner to update the graphical test status. TestResult is an extension point of the framework. Clients can define their own custom TestResult classes, for example, an HTMLTestResult reports the results as an HTML document.

AssertionFailedError An AssertionFailedError is triggered by the assert method provided by TestCase.

JUnit provides a set of assert methods for different purposes. Here is the simplest one:

protected void assert(boolean condition) {     if (!condition)         throw new AssertionFailedError(); }

The AssertionFailedError is not meant to be caught by the client (a testing method inside a TestCase) but inside the Template Method TestCase.run(). We therefore derive AssertionFailedError from Error.

public class AssertionFailedError extends Error {     public AssertionFailedError () {} }

The methods to collect the errors in TestResult are shown below: public synchronized void addError(Test test, Throwable t) {

    fErrors.addElement(new TestFailure(test, t)); } public synchronized void addFailure(Test test, Throwable t) {     fFailures.addElement(new TestFailure(test, t)); }

AssertionFailedError

AssertionFailedError

AssertionFailedError()AssertionFailedError(message : String)

Assert

Error(from lang)

TestFailureTestResult

Observer

TestListener

addError()addFailure()endTest()startTest()

BaseTestRunner(from runner)

TestRunner(from textui)

TestRunner(from swingui)

TestResult

addError()addFailure()addListener()removeListener()

TestRunner(from awtui)

定义对象间一种一对多的依赖关系,当一个对象的状态发生改变时,所有依赖于它的对象都得到通知并被自动更新。

TestResultpublic class TestResult extends Object {

protected Vector fFailures;protected Vector fErrors;protected Vector fListeners;public synchronized void addError(Test test, Throwable t) {

fErrors.addElement(new TestFailure(test, t));for (Enumeration e= cloneListeners().elements(); e.hasMoreElements(); ) {

((TestListener)e.nextElement()).addError(test, t);}

}public synchronized void addFailure(Test test, AssertionFailedError t) {

fFailures.addElement(new TestFailure(test, t));for (Enumeration e= cloneListeners().elements(); e.hasMoreElements(); ) {

((TestListener)e.nextElement()).addFailure(test, t);}

}public synchronized void addListener(TestListener listener) {

fListeners.addElement(listener);}

public synchronized void removeListener(TestListener listener) {fListeners.removeElement(listener);

}}

TestListenerpublic interface TestListener {

/** * An error occurred. */

public void addError(Test test, Throwable t);/**

* A failure occurred. */ public void addFailure(Test test, AssertionFailedError t);

/** * A test ended. */

public void endTest(Test test); /** * A test started. */public void startTest(Test test);

}

TestRunnerpublic class TestRunner extends BaseTestRunner { public synchronized void addError(Test test, Throwable t) {

writer().print("E"); }

public synchronized void addFailure(Test test, AssertionFailedError t) {writer().print("F");

} public synchronized void startTest(Test test) {

writer().print(".");if (fColumn++ >= 40) {

writer().println();fColumn= 0;

} } public void endTest(Test test) { }}

Adapter

Convert the interface of a class into another interface clients expect

Codepublic class TestMoneyEquals extends MoneyTest {

    public TestMoneyEquals(){ super("testMoneyEquals"); }  

   protected void runTest () { testMoneyEquals(); } }

TestCase test= new MoneyTest("testMoneyEquals ") {     protected void runTest() { testMoneyEquals(); }

};

Decorator

TestSetup RepeatedTest

TestDecorator

Test

TestCase

动态地给一个对象添加一些额外的职责。

TestDecoratorpublic class TestDecorator extends Assert implements Test {

protected Test fTest;

public TestDecorator(Test test) {fTest= test;

}/** * The basic run behaviour. */public void basicRun(TestResult result) {

fTest.run(result);}public int countTestCases() {

return fTest.countTestCases();}public void run(TestResult result) {

basicRun(result);}

}

TestSetuppublic class TestSetup extends TestDecorator {

public TestSetup(Test test) {super(test);}public void run(final TestResult result) {Protectable p= new Protectable() {public void protect() throws Exception {setUp();basicRun(result);tearDown();}};result.runProtected(this, p);}

}

Summary

•Command•Template method•Collecting Parameter•Adapter•Pluggables Selector

•Composite•Observer•Decorator•MicroKernel (SA Pattern)

Conclusion

Patterns

We found discussing the design in terms of patterns to be invaluable, both as we were developing the framework and as we try to explain it to others. You are now in a perfect position to judge whether describing a framework with patterns is effective. If you liked the discussion above, try the same style of presentation for your own system.

Pattern density There is a high pattern "density" around TestCase,

which is the key abstraction of JUnit. Designs with high pattern density are easier to use but harder to change. We have found that such a high pattern density around key abstractions is common for mature frameworks. The opposite should be true of immature frameworks - they should have low pattern density. Once you discover what problem you are really solving, then you can begin to "compress" the solution, leading to a denser and denser field of patterns where they provide leverage.

Eat your own dog food As soon as we had the base unit testing

functionality implemented, we applied it ourselves. A TestTest verifies that the framework reports the correct results for errors, successes, and failures. We found this invaluable as we continued to evolve the design of the framework. We found that the most challenging application of JUnit was testing its own behavior.

Intersection, not union There is a temptation in framework development to

include every feature you can. After all, you want to make the framework as valuable as possible. However, there is a counteracting force- developers have to decide to use your framework. The fewer features the framework has, the easier it is to learn, the more likely a developer will use it. JUnit is written in this style. It implements only those features absolutely essential to running tests- running suites of tests, isolating the execution of tests from each other, and running tests automatically. Sure, we couldn’t resist adding some features but we were careful to put them into their own extensions package (test.extensions). A notable member of this package is a TestDecorator allowing execution of additional code before and after a test.

Framework writers read their code We spent far more time reading the JUnit code

than we spent writing it, and nearly as much time removing duplicate functionality as we spent adding new functionality. We experimented aggressively with the design, adding new classes and moving responsibility around in as many different ways as we could imagine. We were rewarded (and are still being rewarded) for our monomania by a continuous flow of insights into JUnit, testing, object design, framework development, and opportunities for further articles.