1 / 19

JUnit v3.7

JUnit v3.7. Introduction. Goals. 개발자들이 실제로 테스트를 하게 하는 프레임웍을 구축한다 . 친근한 인터페이스 새로 익혀야 할 지식 최소화 테스트를 위한 부가적 노력 최소화 신뢰할만한 테스트 결과를 산출한다 . 다양한 형태의 테스트에 적용될 수 있는 확장 가능한 구조를 갖는다. Design – TestCase I. 테스트 작업을 간편히 관리하기 위해 이를 객체화시킨다 . 다양한 형태의 테스트 지원을 위해 확장 가능한 구조를 갖는다 .

Download Presentation

JUnit v3.7

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. JUnit v3.7 Introduction

  2. Goals • 개발자들이 실제로 테스트를 하게 하는 프레임웍을 구축한다. • 친근한 인터페이스 • 새로 익혀야 할 지식 최소화 • 테스트를 위한 부가적 노력 최소화 • 신뢰할만한 테스트 결과를 산출한다. • 다양한 형태의 테스트에 적용될 수 있는 확장 가능한 구조를 갖는다.

  3. Design – TestCase I • 테스트 작업을 간편히 관리하기 위해 이를 객체화시킨다. • 다양한 형태의 테스트 지원을 위해 확장 가능한 구조를 갖는다. • 확장된 여러 테스트들을 일괄적으로 처리할 수 있어야 한다(동일한 인터페이스 유지).

  4. Design – TestCase II • Command Pattern

  5. Design – TestCase III • 테스트 작업을 위한 환경 설정 작업과 실제 테스트 코드를 명시적으로 분리하고자 한다. • 모든 서브클래스에서 ‘설정테스트정리(자원반환 등)’의 순서로 작업이 진행되도록 보장한다.

  6. Design – TestCase IV • Template Method Pattern public void run() { setUp(); runTest(); tearDown(); }

  7. Design – TestResult I • 테스트 과정/결과를 기록하는 메커니즘이 필요하다. • 여러 테스트들의 결과를 종합적으로 관리해야한다.

  8. Design – TestResult II • Collecting Parameter Pattern • TestResult라는 객체를 만들어 테스트 메소드의 입력 인자로 넣는다. • 모든 테스트 메소드는 입력된 TestResult 객체에 정보를 기록한다.

  9. Design – TestResult III • Collecting Parameter Pattern public void run( TestResult result ) { result.startTest( this ); setUp(); runTest(); tearDown(); }

  10. Design – TestResult IV • Collecting Parameter Pattern

  11. Design – TestResult V • Some Methods of TestResult 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) ); }

  12. Design – TestCase V • 하나의 TestCase 클래스에 개별적인 테스트를 원하는 여러 메소드들이 존재할 수 있다. • Command Pattern은 run() 메소드 하나만을 명시하므로 이에 대처할 수 없다.

  13. Design – TestCase VI • Pluggable Selector • Reflection 을 이용해 어떤 메소드를 테스트할 지를 결정한다. void runTest() throws Throwable { Method runMethod = getClass(). getmethods(fName, new Class[0]); runMethod.invoke(this, new Class[0]); }

  14. Design – TestCase VII • Adapter Pattern • TestCase 를 확장하여 runTest() 메소드를 오버라이딩하여 같은 목적을 달성한다.

  15. Design – TestCase VIII

  16. Design – TestSuite I • 여러 테스트를 한꺼번에 수행할 수 있어야 한다. • 호출자 입장에서는 테스트가 하나이건 여러 개이건 상관없이 동일한 인터페이스로 접근하고자 한다.

  17. Design – TestSuite II • Composite Pattern • 기본 개념 • Component: 외부에서 다루고자 하는 객체의 인터페이스 • Composite: 스스로 Component이면서 다른 여러 Component를 포함 • Leaf: Component이나 다른 Component를 포함하지는 않음

  18. Design – TestSuite III • Composite Pattern

More Related