블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 
 

단위 테스트 1회 (JUnit)

ALM/Test Automation | 2007.11.23 11:11 | Posted by 조대협

단위 테스트 (Unit Test)

 

2007-08-27

자바스터디 조대협(bcho.tistory.com)

 

현재 BEA Systems Korea Senior Consultant로 근무하고 있다.

SOA/SCA,EP,EAI등에 대한 기업 솔루션에 대한 아키텍쳐 컨설팅을 주로 하고 있으며, WAS 기반의 아키텍쳐 튜닝, 장애 대응에 대한 많은 경험을 가지고 있다.

 

1. 단위 테스트의 기초

2. 확장된 단위 테스트 도구

3. Test Coverage 분석

 

오래간만에 실제 프로젝트에 코더로써 참가하였다.

엔지니어 시절부터 장애나 버그, 성능에 대한 문제를 어떻게 방지할 수 있을까에 대해서 고민하고, 문제의 추적이나 장애 대처 방안, 회피 아키텍쳐들을 고민해왔지만, 애플리케이션상에서 발생하는 문제는 발견은 할 수 있지만, 발견에 드는 비용이 크고 무엇보다 문제를 미리 예방하는 것보다는 어떤 방식이라도 비효율적일 수 밖에 없다.

 

이런 고민을 하던중 자바기반의 프로젝트 관리에서 IDE이용한 개발과, 소스 버전관리 자동 빌드, 테스트와 이슈 트랙킹등의 자동화된 프로젝트 관리론에 대해 관심을 돌리게 되었고, 간단하게나마 Unit 테스트에 대해서 정리해보고자 한다.

 

1. 테스트

소프트웨어 개발에서 테스트란, ‘요구사항에 의해 개발된 산출물이 요구사항과 부합하는지 여부를 검증하기 위한 작업’이다. 소프트웨어 컴포넌트가 기능적으로 잘 작동하는지 뿐만 아니라 넓은 의미에서 고객의 요구사항이 제대로 이해되어 반영이 되었는지 등의 모든 검증 작업을 테스트로 생각할 수 있다.

많은 소프트웨어 개발자나 엔지니어들이 “테스트”의 필요성과 중요성에 대해서 인정한다. 그러나 이 “테스트”에 시간을 투자하기 보다는 비즈니스 로직에 시간을 투자하는 것 구현체에 시간을 투자하는 것을 더 중요한 일로 생각한다. (실제 프로젝트 종료 시간이 임박해 오니까는) 또는 “테스트”를 소프트웨어 개발이 완료된 후에 하는 것으로 생각한다.

테스트되지 않고 마감일에 맞추어진 시스템은 버그에 의해서 그보다 더 많은 시간을 버그 수정에 쏟아 붓게 되고 그러다 보면 코드는 어느새 스파게티 처럼 엉켜 버릴것이다.

 

전통적인 소프트웨어 개발 프로세스를 보면 아래 그림과 같이 요구사항의 분석,설계,구현,테스트의 과정을 거치게 된다. 각 과정별로 검증을 할 수 있는 테스트 방법과 도구가 존재하고 이를 통해서 문제를 단계별로 미리 해결함으로써 나중에 문제 해결과 발생에 소요되는 시간과 비용을 혁신적으로 줄일 수 있다.

사용자 삽입 이미지

< 그림 1. 전통적인 소프트웨어 개발 프로세스 >

 

(1)  요구 사항 분석 단계의 검증

요구 사항 분석 단계의 검증은 고객의 요구 사항을 분석가가 제대로 이해하였는지 검증에서 시작한다. 소프트웨어 개발 프로젝트의 대부분의 실패 원인은 잘못된 요구 사항 분석이 많은 비중을 차지한다.

 

이 과정에서 필요한 것이 바로 소프트웨어 명세서이다.

이 명세서에는 기능적인 요구 사항과, 비기능적 요구 사항(성능,장애에 대한 대처 방법)등이 기술되어야 하며, 우선적으로 반영되어야할 내용에 대한 우선순위가 설정되어야 한다.

이 명세서를 고객에게 CONFIRM받는 것으로써, 요구사항이 적절히 수집되었는지 여부를 확인할 수 있다.

그러나, 명세서를 아무리 잘 작성한다고 해도, 실제 돌아가는 애플리케이션이 아니기 때문에 의사소통에 있어서 문제가 발생할 수 있다.

고객은 “A”라고 이야기 했지만, 분석가는 “a”로 이해한 경우라고나 할까?

이를 좀더 명확하게 하기 위해서 우리는 몇가지 도구를 이용할 수 있는데, 가장 효과적이라고 생각하는 것은 바로 PILOT 프로젝트 또는 시제품이다.

 실제 기능은 구현되지 않은 UI기반의 시스템을 작성하는 것이다. Visual Basic과 같은 4GL이나 Flex와 같은 RIA(Rich Internet Application)등을 이용하면 손쉽게 작성할 수 있고, 또는 HTML기반으로 구현될 웹사이트를 만들 수 도 있다. 이는 실제로 고객의 요구 사항을 정확하게 수집하여 나중에 발생될 수 있는 문제를 미연에 방지함으로써 중복 개발이나, 잘못 분석된 요구사항으로 인해서 시스템을 뒤집어 엎는 일을 막아줌으로써, PILOT 제품을 만드는데 소요된 비용을 보상한다.

 위의 PILOT 제품 이외에, 프로세스(업무 절차)가 복잡한 경우에는 BPA(Business Process Analyze) 솔루션을 이용하여 프로세스를 순서도로 도식화하고 흐름에 대한 검증을 함으로써 복잡한 프로세스에 대한 문제도 검증할 수 있다.

 

 단 몇가지 주의할점은 고객은 대부분 기술적이지 못하기 때문에 (적어도 개발자보다는 기술적이지 못할것이다.) 파일럿으로 만들어진 제품을 보고 고객은 “폰트를 바꿔 주세요.” “표 간격이 멀어요..” 등의 기능이 아닌 화면 디자인을 가지고 이슈를 삼을지도 모른다. 물론 디자인에 대한 요구사항 수집 역시 중요한 일이지만, 기능적인 요구 사항 이외의 디자인적 이슈를 다루기 위한 파일럿이 아니라는 것을 고객에게 인식 시키고 기능적 요구사항에만 집중할 필요가 있다. 디자인팀이 고객으로부터 디자인에 대한 요구 사항의 수집을 원한다면, 기능적인 이슈에 대한 수집이 끝난후에, 파일럿 제품에 대한 디자인을 차차 변경해나가도 될 것이다.

 

※ 이글은 단위 테스트에 대해 소개하는 글이지만, 요구 사항 분석에 대한 중요성이 높기 때문에 다소 길게 요구사항 분석에 대한 검증 기법에 대해서 설명하였다

.

(2)  시스템 디자인 단계의 검증

분석된 요구 사항을 UML이나 각종 방법론을 이용해서 소프트웨어 디자인을 진행할것이다. 여기에서 특정한 테스팅 방법론을 적용하기는 매우 어렵다. 데이터 베이스의 정규화나, 또는 디자인 패턴을 이용한 설계 방법론 정도라고나 할까?

다행히 복잡한 비즈니스 프로세스에 대해서는 BPA솔루션에서 시뮬레이션을 해볼 수 는 있지만, 테스팅 방법론으로 접근하는 것보다는 소프트웨어 설계 방법론으로 접근하는 것이 좋을것이다. 자세한 내용은 Software Design에 관련된 문서들을 참고하기 바란다.

 

(3)  구현 단계의 검증

본 문서에서 다루고자 하는 부분이 구현에 대한 검증이다.

실제로 구현 (Implementation)이 들어갔을 때, 어떻게 테스트를 할것인가에 대한 검증작업인데, 소프트웨어의 구현 작업은 크게 나누면 2가지 단계로 나눠볼 수 있다. 각각의 컴포넌트를 작성하는 것과 이 작성된 컴포넌트를 통합(Integration) 하는 단계이다.

 

컴포넌트를 구현하는 단계에서는 각 컴포넌트가 디자인된 의도데로 작동하는지를 검토하는 “단위 테스트”(Unit Test)를 적용할 수 있고, 통합이 된 후에는 “통합 테스트” (Integration Test)를 수행한다.

 

개발 과정에서 이 두가지 테스트는 고객의 요구사항과 무관하게 진행되어야 한다. “구현된 소프트웨어 자체가 디자인된 데로 작동하는가” 여부를 판단하는 테스트이다.

소프트웨어가 고객의 요구사항데로 디자인되고 그대로 작동하는가 여부는 테스트 단계에서 인수 테스트 (Acceptance test) 과정에서 검증된다.

 

이 글에서는 구현 단계 검증에서 특히 컴포넌트 테스트 “단위 테스트”에 대해서 설명하고자 한다.

 

(4)  테스트 단계의 검증

통합 테스트까지 완료되었으면 우리 손에는 완성된 제품이 있는 것이다.

이 제품을 고객에게 넘기기 위해서 고객의 요구 사항을 충족하고 있는지에 대한 테스트가 필요하다. 이 테스트는 앞에서 설명한 인수 테스트(Acceptance test)이다.

먼저 고객의 요구사항에 기술된 기능이 제대로 구현되었는지에 대한 기능적 테스트가 필요하고, 장애나 성능에 대한 비기능 테스트가 필요하다.

 

기능 테스트는 정해진 시나리오에 따라 입력된 값에 대해서 적절한 출력값이 나오는가를 검증해야 한다. 이런 테스트는 일반적으로 자동화된 도구 보다는 고객의 Heuristic (사람이 테스트 하는) 하게 테스트 하는 경우가 많다.

 

비 기능적 테스트는 기본적으로 성능 테스트와 장애 테스트가 많이 이루어진다.

이런 테스트를 위해서는 실환경과 유사한 환경을 재현해주는 것이 필요한데, 재현을 위해 사용되는 도구가 부하 발생기이다. 대표적인 상용 도구로는 Load Runner가 있고, 무료로 사용할 수 있는 도구로는 Apache JMeter, MicrosoftMS Stress등이 있다.

 

이 테스트 단계에서 각종 튜닝과 장애 원인 분석, 배포 아키텍쳐에 대한 재 분석, 용량산정 등을 수행할 수 있는데, 이 강좌의 내용과는 논외니까는 여기까지만 설명하도록 한다.

 

2. 단위 테스트 도구

 

단위 테스트의 정의를 살펴보자, Pragmatic Unit Testing에서 단위 테스트를 다음과 같이 정의하고 있다.

단위 테스트는 테스트 대상이 되는 코드 기능의 아주 작은 특정 영역을 실행해 보는, 개발자가 작성한 코드 조각이다. 대개 단위 테스트는 특정 상황에서 특정 메서드를 시험해 본다. 예를 들어 어떤 정렬된 리스트에 큰 값을 넣고 이 값이 리스트 끝에 들어가 있는지 확인해볼 수 있다.

단위 테스트는 위에서 설명한 말 그대로 개발자가 작성한 컴포넌트가 입력값에 대해서 적절한 출력값을 리턴하는 지를 체크하는 것이다.

 

이런 테스트 코드는 JDK 1.4 이상의 assertion등을 사용할 수 도 있겠지만, 일일이 이런 테스트를 만들고, 자동으로 이러한 테스트를 실행하기 위한 코드를 작성하기 위해서는 많은 작업이 필요하다.

 

이런 작업들을 덜어주기 위해서 xUnit 테스트 프레임웍들이 존재한다.

몇가지 단위테스트 도구에 대해서 알아보도록 하자.

 

(1)   JUnit

JUnit은 자바 애플리케이션의 단위 테스트 자동화를 위한 프레임웍이다.

상당히 사용하기 쉽고, Eclipse와 같은 IDE,ANT와 같은 빌드 스크립트에도 쉽게 통합이 되기 때문에 가장 널리 사용되고 있다.

 

현재 사용되는 버전은 3.8버전과 4.X 버전이 있는데, 4.X 버전의 경우 “@ Annotation을 사용하면서 문법이 변경되었기 때문에 주의를 필요로한다. (본 문서에서는 3. 버전을 기준으로 설명한다.)

JUnit 테스트에 대해서 간략하게 예를 들어보면 다음과 같다.

테스트를 위한 Test 클래스를 생성한다.

테스트 클래스는 junit.framework.TestCase를 상속 받아서 구현하며, 테스트 메서드는 testXXX 메서드로 구현한다.

testXXX메서드에서 테스트는 assertXXX 메서드를 이용하여, 테스트의 성공 여부를 체크한다.

다음과 같은 클래스가 있다. getCurrentVersion() 메서드는 “version 1.0”이라는 문자열을 항상 리턴해야 한다. 이 메서드의 유효성을 체크하기 위해서 테스트 클래스를 작성하면

package bcho;

 

public class HelloWorld {

       public String getCurrentVersion(){

             return "version 1.0";

       }

}

 

다음과 같이 간단한 테스트 클래스를 만들 수 있다.

package bcho.test;

 

import junit.framework.TestCase;

import bcho.HelloWorld;

public class HelloWorldTest extends TestCase {

 

        public void testGetCurrentVersion() {

               HelloWorld hw = new HelloWorld();

               assertEquals(hw.getCurrentVersion(), "version 1.0");

        }

 

}

testGetCurrentVersion에서 getCurrentVersion이 리턴 문자열이 “version 1.0”인지 테스트를 해주는 클래스이다.

이클립스에서 이 테스트 유닛을 수행하면, 각 테스트의 통과 여부를 보여준다.

사용자 삽입 이미지

 

기본적으로 JUnit은 테스트 클래스에 포함된 모든 testXXX 메서드들을 테스트로 수행하는데, 상황에 따라서 모든 테스트 메서드가 아닌 일부 메서드만 수행하고 싶은 경우가 있다. 이럴 경우 public static Test suite(); 라는 메서드를 오버로딩함으로써 구현을 할 수 있다.

 

아래 예제는 suite 메서드를 이용한 테스트를 조합한 예이다.

이 테스트 클래스를 이용하면, 두개의 test 메서드중에서 testGetCurrentVersion2

테스트만 수행되게 된다.

package bcho.test;

 

import junit.framework.Test;

import junit.framework.TestCase;

import junit.framework.TestSuite;

import bcho.HelloWorld;

public class HelloWorldTest extends TestCase {

 

       public void testGetCurrentVersion() {

             HelloWorld hw = new HelloWorld();

             this.assertEquals(hw.getCurrentVersion(), "version 1.0");

       }

       public void testGetCurrentVersion2() {

             HelloWorld hw = new HelloWorld();

             this.assertEquals(hw.getCurrentVersion(), "version 2.0");

       }

       public HelloWorldTest(String method){

             super(method);

       }

       public static Test suite(){

             TestSuite suite = new TestSuite();

      

             suite.addTest(new HelloWorldTest("testGetCurrentVersion2"));

             return suite;

       }

}

< 그림. suite 메서드를 이용한 테스트의 조합 >

 


사용자 삽입 이미지
 

< 그림.  suite 메서드를 이용한 테스트의 조합 테스트를 수행한 결과 >

 

testXXX메서드를 구현할 때, testXXX에 대해서 공통적으로 구현되어야할 부분이 존재할 수 있다. 예를 들어서 test마다 데이터베이스 Connection Close 작업이 필요하거나, 공통적으로 test메서드에서 File Descriptor(FD)를 사용하기 때문에 매번 File Open Close가 일어날 경우등이 있다.

이러한 메서드들을 매번 testXXX 메서드에 구현할 수도 있겠지만, 모든 testXXX메서드들이 메서드 전후에 수행할 수 있는 메서드들이 있다.

l         protected void setUp();

l         protected void tearDown();

이 둘이 그 메서드들이다. 다음 예제를 보자, 다음 예제는 testXXX메서드를 수행하기 이전, 이후에 매번 데이터 베이스 연결을 열고 닫도록 구현한 코드이다.

       private Connection conn;

       protected void setUp(){

             try{

                    conn = getConnection("10.136.21.1","oracle","oracle");

             }catch(Exception e){

                    e.printStackTrace();

                    this.fail("Fail to open DB Connection");

             }     

       }

       protected void tearDown(){

             if(conn != null){

                    try{

                           conn.close();

                    }catch(Exception e){

                           e.printStackTrace();

                           this.fail("Fail to close DB Connection");

                    }

             }

       }

< 예제. setUp() tearDown()이용한 데이터베이스 연결 관리 예제 >

 

메서드 전후에 수행할 수 있는 메서드 이외에도, JUnit에서는 Test의 묶음 (위에서 설명한 Suite)단위의 setUp teardown 메서드를 제공한다. 여기서 적용된 클래스는 suite수행은 전후에 단한번씩만 수행된다. 구현 방법은 suite Object를 생성한후에, TestSetup이라는 클래스로 Wrapping하여 suite 메서드 내에서 return하면 된다.

       public static Test suite(){

             TestSuite suite = new TestSuite();

            

             suite.addTest(new HelloWorldTest("testGetCurrentVersion2"));

             TestSetup wrapper = new TestSetup(suite){

                    protected void setUp(){

                           // doSomething for initial phase

                    }

                    protected void tearDown(){

                           // doSomething after end phase

                    }

             };

             return wrapper;

       }

< 예제. setUp() tearDown suite에 구현한 예제 >

 

지금까지 간단하게나마 JUnit에 대한 사용법에 대해서 살펴보았다. 이외에도 Exception처리 등 몇가지 필요한 사항이 있지만, 본 강의는 JUnit의 사용법이 아니라 단위 테스트에 대한 전반적인 개념을 소개하기 위한 글이 기 때문에, JUnit에 대한 사용법은 http://www.junit.org/index.htm 의 문서나 또는 [실용주의 프로그래머를 위한 단위 테스트 with JUnit – 인사이트 ] 등의 서적을 참고하기 바란다.

 

지금까지 JUnit을 통한 기본적인 Java Application의 테스트 방법에 대해서 알아보았다. 단위 테스트를 Pure Java JUnit이용해서 작성해도 좋겠지만, 데이터베이스 테스트나 Servlet/JSP, EJB,JMS Java 세계에는 여러가지 특성을 가진 컴포넌트들이 존재하며, 이를 Pure Java Code로만 만들기에는 다소 많은 작업이 필요하다.

 

지금부터 일반적인 단위 테스트 프레임웍에 대해서 소개한다.

 

(2)   DBUnit

인터넷 서비스 애플리케이션이나 엔터프라이즈 애플리케이션에서 많은 비중을 차지 하는 것이 데이터베이스 관련 작업일 것이다.

이런 데이터 베이스 단위테스트를 지원하는 프레임웍으로는  DBUnit이라는 것이 있다.

테스트 시나리오를 요약해보면 다음과 같다.

1)     테스트 데이터베이스를 초기화 한다.

데이터베이스의 초기화는 XML파일에서 데이터 로딩등의 통해서 DB를 초기화할 수 있다.

2)     테스트할 객체를 수행한다.

3)     데이터베이스에서 2)에 의해 수행된 결과를 쿼리한다.

4)     XML 파일등으로부터 기대 결과를 로딩한다.

5)     3) 4) assert 메서드를 이용하여 비교한다.

6)     데이터 베이스를 테스트 전 상태로 원상 복구한다.

 

아래 예제코드를 살펴보자.

DB 단위 테스트이기 때문에 DBMS에 대한 Connection관리가 필요한데, 베이스클래스 인

DBTestCase getConnection 메서드와 closeConnection 메서드에 의해서 이루어진다.

 

직접 getConnection closeConnection 메서드를 구현할 수 도 있지만, System Property에 필요한 URL,ID,PASSWORD등을 지정하면, 자동으로 DBUnit에서 Connection 관리에 대한 메서드를 제공한다.

public class EmpDAOTest extends DBTestCase

{

       final static String JDBC_DRIVER="org.gjt.mm.mysql.Driver";

       final static String JDBC_USERID="user";

       final static String JDBC_USERPASSWD="password";

       final static String JDBC_URL

="jdbc:mysql://localhost:20001/dbms";

 

       public EmpDAOTest(String name){

             super(name);

           System.setProperty( PropertiesBasedJdbcDatabaseTester.DBUNIT_DRIVER_CLASS, JDBC_DRIVER );

           System.setProperty( PropertiesBasedJdbcDatabaseTester.DBUNIT_CONNECTION_URL, JDBC_URL );

           System.setProperty( PropertiesBasedJdbcDatabaseTester.DBUNIT_USERNAME, JDBC_USERID );

           System.setProperty( PropertiesBasedJdbcDatabaseTester.DBUNIT_PASSWORD, JDBC_USERPASSWD );

 

       }

 <예제, DBUnit에서 Connection을 관리하는 부분 >

 

위의 예제에서는 Connection에 관련된 Property값을 System.setProperty이용해서 지정하였지만, ANT나 시스템환경 변수를 이용해서 지정하는것도 가능하며, 위의 예제는 JDBC Driver를 통해서 직접 연결하는 예제이지만, 설정값에 따라서 DataSource,JNDI이용하는것도 가능하다.

 

데이터 베이스 연결을 위한 메서드가 구현되었으면, 테스트전의 데이터 베이스 초기화를 위한 작업이 선행 되어야 한다. 이 작업은 getSetUpOperation  에서 이루어진다. 이 메서드는 테스트가 진행되기전에 수행되어 리턴값에 따라서 데이터베이스를 초기화 하는데, CLEAN_INSERT는 데이터베이스를 모두 지우고, getDataSet에 의해서 리턴되는 Record들을 Insert하여 데이터베이스를 초기화 한다. 아래 예제에서는 초기화 Record 값들을 FlatXmlDataSet이용하여, dataset.xml에서 읽어서 그 데이터로 초기화를  수행하도록 구현하였다.

 getSetUpOperation에서 사용할 수 있는 리턴값으로는 , 모든 데이터를 지우는 DELETE_ALL 이나 INSERT,UPDATE등의 작업을 수행할 수 있다.

 

모든 테스트가 종료된 다음에는 데이터베이스를 원상복구하기 위해서 getTearDownOperation  메서드에서 getSetUpOperation  과 같은 방법으로 정리 작업을 수행한다.

 

protected DatabaseOperation getSetUpOperation()

throws Exception

{

        return DatabaseOperation.CLEAN_INSERT;

}

protected DatabaseOperation getTearDownOperation()

throws Exception

{

        return DatabaseOperation.NONE;

}

protected IDataSet getDataSet() throws Exception

{

             return new

FlatXmlDataSet(new FileInputStream("c:\\temp\\dataset.xml"));

}

 

< 예제 . 데이터 초기화 방법 >

 

<?xml version='1.0' encoding='euc-kr'?>

 

<dataset>

        <BCHO_EMP name='bcho'

                 address='Seoul Korea'/>

</dataset>

< 예제. 데이터 초기화에 사용된 dataset.xml >

 

자 여기까지 구현하였으면, 데이터베이스 테스트를 하기 위한 준비가 완료되었다. 이제부터 실제로 테스트 메서드를 작성해보자. 테스트 메서드는 위에서 설명한데로, 테스트할 메서드를 호출하고, 반영된 결과를 DBMS로부터 읽어서 기대되는 결과와 비교하면 된다.

public void testInsertEmployee(){

IDatabaseConnection conn = null;

try{

       // 1. 테스트할 객체를 호출하여 데이터베이스를 업데이트 한다.

       EmpDAO empDao = new EmpDAOImpl();

       empDao.insertEmployee("kim", "YoungIn Suji");

                   

       // 2. 업데이트 내용이 반영된후, 반영된 내용을 DBMS로부터 읽어온다.

       conn = getConnection();

       IDataSet databaseDataSet = conn.createDataSet();

       ITable actualTable

= databaseDataSet.getTable("BCHO_EMP");

                   

       // 3. 비교할 내용을 XML파일에서 읽어온다.

       IDataSet expectedDataSet

= new FlatXmlDataSet(new File("c:\\temp\\dataset.xml"));

       ITable expectedTable = expectedDataSet.getTable("BCHO_EMP");

 

       // 4. 위의 2,3 내용이 일치하는지 비교한다.

       Assertion.assertEquals(expectedTable,actualTable);

}catch(Exception e ){

             e.printStackTrace();

             fail("Test failed during testEmpTable");

}finally{

             try{

                    closeConnection(conn);

             }catch(Exception e){

                    fail("Fail to close connection");

             }//try-catch

}//finally

            

}

예제에서와 같이 EmpDAO이용하여, BCHO_EMP” 테이블을 업데이트 한후에, 업데이트 된 내용을  2항에서 actualTable이라는 객체로 받아내고, dataset.xml에서 비교할 데이터를 expectedTable형태로 받아온다.

이 둘을 비교하여, 테스트를 수행한다.

 

이 예제에서는 간단하게 두개의 테이블을 비교했지만, SELECT를 해서 테이블의 SUBSET으로만 비교하거나 또는 특정 컬럼들만 비교하는 것이 가능하다.

테스트 데이터를 예제에서는 XML파일에서 읽도록 하였지만, CSV파일에서 읽어 드리는 것도 가능하며, XML  테스트 데이터도 DBMS에서 Generate하거나 DTD역시 DBMS의 쿼리 결과를 이용해서 자동으로 생성할 수 있다.

 ( 참고 : http://dbunit.sourceforge.net/faq.html#extract )

 

간단하게나마 DBUnit의 사용법에 대해서 살펴보았다. 특히 Enterprise Application의 경우 데이터에 대한 작업이 매우 중요하기 때문에, 데이터 검증에 대한 단위테스트는 매우 중요하다. DBUnit의 경우 RDBMS에 대한 테스트도 지원하지만, FlatXmlDataSet이용해서 XML데이타 검증등에도 손쉽게 사용할 수 있다.

 

DBUnit이용하여 데이터베이스 관련 테스트를 진행할 경우에는 DBMS를 공유하여 협업을 할 경우에는 데이터에 대한 간섭이 일어날 수 있기 때문에, 가능하다면 독립된 테스트 데이터 베이스 (LOCAL PC도 좋다)를 유지하는 것을 권장한다.

 

이번 회에서는 테스트의 개념과 단위 테스트의 개념에 대해서 알아보았고, 이를 구현하기 위한 가장 기본적인 JUnit과 데이터베이스 테스트를 위한 DBUnit에 대해 알아보았다.

다음 회에서는 좀더 확장된 단위 테스트 도구를 이용한 단위 테스트 방법에 대해서 소개하도록 한다.

 

'ALM > Test Automation' 카테고리의 다른 글

Cactus 테스트시 주의 할점  (0) 2008.01.17
JUnitPerf  (0) 2008.01.16
단위 테스트 1회 (JUnit)  (1) 2007.11.23
Test Coverage 분석툴  (0) 2007.11.08
Cactus 실행용 ANT 스크립트  (0) 2007.09.13
Cactus 빌드 스크립트 샘플  (0) 2007.09.12
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

  1. 달타냥 2008.01.10 01:35  댓글주소  수정/삭제  댓글쓰기

    이번달 마소에서 좋은 기사 잘봤습니다~~ 저희회사 내의 액션스크립트 개발자들도 어도비의 단위테스트를 활용할까한답니다. 적당한 시기에 좋은기사 써주셔서 유익하게 읽었습니다. ^^;;

Atlassian Bamboo

ALM/Build Automation (빌드 자동화) | 2007.11.08 16:58 | Posted by 조대협
http://www.atlassian.com/software/bamboo/

빌드 배포 시스템을 고민하고 있는데.
(사실 본업은 아니다. 아무리 컨설턴트라도 BEA 제품을 컨설팅 해야지.. 이걸 하는건 개인 취미일까? -_-)

그동안 Cruise Control을 적용해볼 생각만 가득했는데.
N社 박재성 팀장님과 이야기 하던중 Bamboo를 듣게 되어서 오늘 찾아보았다.
자동화된 빌드는 물론이고,
Fish Eye 연동으로 변동 된 부분을 보여주고 JIRA와 연동, 그리고 빌드가 깨졌을때 (테스트가 깨졌을때)나 성공했을때 빌드 결과를 메신져로 보내준다던지.
Repository와 연동이 된다던지 한마디로 Seamless integration인데..

상용툴인 만큼 상당히 마음에 든다.

'ALM > Build Automation (빌드 자동화)' 카테고리의 다른 글

이제는 Trac  (1) 2008.01.24
Hudson  (0) 2008.01.22
Atlassian Bamboo  (0) 2007.11.08
일일 빌드에 대해서..  (0) 2007.10.17
하나의 소스를 여러 환경에 DEPLOY하는 방법  (0) 2007.08.24
SVN CheckOut and Build 자동화 스크립트 예제  (0) 2007.08.23
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.
TAG BAMBOO

댓글을 달아 주세요

Test Coverage 분석툴

ALM/Test Automation | 2007.11.08 16:36 | Posted by 조대협
http://cobertura.sourceforge.net/
http://emma.sourceforge.net/

요즘 빌드 자동화와 테스트 커버러지에 관심이 많은데.
거기에 해당하는 툴.
위에 툴 둘다 재미있는게, 실제 소스코드에서 테스트가 된곳과 안된곳을 하이라이트 처리해준다는것이 매우 흥미롭네.
EJB도 그만큼 잘 지원해줄려나?

물론 돈만 있다면
http://www.cenqua.com/clover/
클로버를 쓰고 싶은데.. ^^;

==
형준이 말로는 JCoverage가 좋다네.

'ALM > Test Automation' 카테고리의 다른 글

JUnitPerf  (0) 2008.01.16
단위 테스트 1회 (JUnit)  (1) 2007.11.23
Test Coverage 분석툴  (0) 2007.11.08
Cactus 실행용 ANT 스크립트  (0) 2007.09.13
Cactus 빌드 스크립트 샘플  (0) 2007.09.12
Unit Testing WebLogic Workshop 8.1 Applications & JWebUnit  (0) 2007.08.27
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

Dependency 분석 도구

ALM | 2007.11.05 20:49 | Posted by 조대협

http://www.ewaypartners.com/ 에서 수입해서 파는 툴 같은데.
스팸 이메일로 받았다가 흥미가 있어서 살펴보았다.
http://www.lattix.com/dl/demo/LDMdemo-01-01.htm

소스 코드간 Dependency를 Syntanx check로 체크해서 Matrix로 보여주는 모델인데,
어느정도 소스간의 Dependency 분석을 통해서 변경에 대한 Impact를 예측할 수 있을 듯 싶다.

그러나!!. 동적 Class Loading이나 또는 Spring을 이용한 DI, 또는 각종 Java AP의 configuration에 따른 Dependency 관리는 어려울것 같으니... 결국 보조적인 툴 정도로만 사용이 될텐데. 그래도 편리 하지 않을까?

변경에 대한 Impact관리도 이런 툴이 나올때가 되긴 되었다.
아니면 Spring의 DI를 이용해서 객체간 Dependency Map을 잘 관리 하는것도 하나의 방법이 될듯

'ALM' 카테고리의 다른 글

빌드 자동화 연동에 대한 고민  (0) 2008.02.29
개발환경 자동화 환경  (5) 2008.02.28
프로젝트 자동화 도구..  (3) 2008.01.18
Dependency 분석 도구  (0) 2007.11.05
XPlanner  (0) 2007.10.23
WLW 10.1 (Flex 지원)  (2) 2007.10.09
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

XPlanner

ALM | 2007.10.23 11:52 | Posted by 조대협
http://www.xplanner.org/index.html

XP기반의 프로젝트 관리툴.
스케쥴 관리등이 가능.

'ALM' 카테고리의 다른 글

빌드 자동화 연동에 대한 고민  (0) 2008.02.29
개발환경 자동화 환경  (5) 2008.02.28
프로젝트 자동화 도구..  (3) 2008.01.18
Dependency 분석 도구  (0) 2007.11.05
XPlanner  (0) 2007.10.23
WLW 10.1 (Flex 지원)  (2) 2007.10.09
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.
TAG XPlanner

댓글을 달아 주세요

일일 빌드는 소스 코드의 에러율을 낮추주고
일정을 중간 중간 체계적으로 체크할 수 있는 여러점에서 유용하다.
그러나. 일일 빌드를 자동화 하지않을 경우에는
잊혀지기 쉽고.. 그 이점을 찾기가 어렵다.
일일 빌드는 자동화가 필요하다.

'ALM > Build Automation (빌드 자동화)' 카테고리의 다른 글

이제는 Trac  (1) 2008.01.24
Hudson  (0) 2008.01.22
Atlassian Bamboo  (0) 2007.11.08
일일 빌드에 대해서..  (0) 2007.10.17
하나의 소스를 여러 환경에 DEPLOY하는 방법  (0) 2007.08.24
SVN CheckOut and Build 자동화 스크립트 예제  (0) 2007.08.23
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

WLW 10.1 (Flex 지원)

ALM | 2007.10.09 09:57 | Posted by 조대협

내가 BEA를 떠날 수 없는 이유중에 하나는
BEA는 항상 정말 재미있는 기술들을 만들어낸다는 것이다.
이런게 필요하지 않을까 생각하고 있으면 몇달후에, 그 제품들을 떡하니 가져다 놓는다.
그리고 공부할 수 밖에 없는 상황으로 만들어 버린다.

이번에는 WebLogic 개발 환경은 WebLogic Workshop 에 Flex Builder가 포함되어 버렸다.
기존 WLW에서 Opensource (JSTL,Struts,Hibernate,JDO,Spring,Beehive)를 지원한데 이어서 또 다른 획기적인 일이다.
이제 Eclipse 안에서만 개발을 하면 모든 Java AP개발을 끝이 날 듯 싶다.

사용자 삽입 이미지

'ALM' 카테고리의 다른 글

빌드 자동화 연동에 대한 고민  (0) 2008.02.29
개발환경 자동화 환경  (5) 2008.02.28
프로젝트 자동화 도구..  (3) 2008.01.18
Dependency 분석 도구  (0) 2007.11.05
XPlanner  (0) 2007.10.23
WLW 10.1 (Flex 지원)  (2) 2007.10.09
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.
TAG eclipse, flex, WLW

댓글을 달아 주세요

  1. 열이아빠 2007.10.09 10:29 신고  댓글주소  수정/삭제  댓글쓰기

    국내에서 WLW 을 얼마나 사용하고 있나요.
    지난번 Flex 지원 발표났을때 얼마나 사용하는지 궁금해서
    몇몇 커뮤니티에 글을 올려보았는데
    쓰신다는 분이 없으셔서 (물론 답글이 없던거지만요..)

  2. 조대협 2007.10.10 11:22  댓글주소  수정/삭제  댓글쓰기

    생각보다 많이 사용하지요.
    기본적으로 BEA 제품군은 포탈,EAI등은 모두 WLW로 개발하도록 되어 있으니까요.
    사용하시는분들이 이클립스 기반이라서 WLW로 인식을 못하셔서 그렇지 생각보다 사용하시는 분이 꽤나 많습니다.

Cactus 실행용 ANT 스크립트

ALM/Test Automation | 2007.09.13 12:22 | Posted by 조대협

<project name="CactusTest" default="cactus-test" >

 <!--
 =============================================================================================
 기본 환경 정보 설정
 =============================================================================================
 -->
 <!-- 기본 디렉토리 정보 -->
 <property name="project.name" value="Cactus"/>
 <property name="lib" value="./lib"/>
 <property name="src" value="./src"/>
 <property name="build" value="./build"/>
 <property name="packaging" value="./pack"/>
 <property name="conf" value="./conf"/>

 <property name="cactus.home" value="D:\dev\lib\jakarta-cactus-13-1.7.2"/>
 <property name="cactus.testlog" value="c:\temp\test-report"/>
 <property name="tomcat.home" value="D:\dev\apache-tomcat-5.5.23\"/>

 <!-- jar 파일 경로 -->
 <property name="cactus.jar" value="${cactus.home}/lib/cactus-1.7.2.jar"/>
 <property name="cactus-ant.jar" value="${cactus.home}/lib/cactus-ant-1.7.2.jar"/>
 <property name="commons-httpclient.jar" value="${cactus.home}/lib/commons-httpclient-2.0.2.jar"/>
 <property name="commons-logging.jar" value="${cactus.home}/lib/commons-logging-1.0.4.jar"/>
 <property name="aspectjrt.jar" value="${cactus.home}/lib/aspectjrt-1.2.1.jar"/>
 <property name="cargo.jar" value="${cactus.home}/lib/cargo-0.5.jar"/>
 <property name="servletapi.jar" value="${lib}/servletapi-2.3.jar"/>
 <property name="junit.jar" value="${lib}/junit-3.8.1.jar"/>

 <!-- class path 설정 -->
 <path id="cactus.classpath">
     <pathelement location="${cactus.jar}"/>
     <pathelement location="${cactus-ant.jar}"/>
     <pathelement location="${commons-httpclient.jar}"/>
  <pathelement location="${commons-logging.jar}"/>
  <pathelement location="${aspectjrt.jar}"/>
  <pathelement location="${cargo.jar}"/>
  <pathelement location="${junit.jar}"/>
 </path>
 <!--
 =============================================================================================
 Task 정의
 =============================================================================================
 -->
 <!-- Cactus task 정의 -->
 <taskdef resource="cactus.tasks" classpathref="cactus.classpath"/>
 
 <!-- Clean -->
 <target name="clean">
  <delete dir="${build}"/>
  <mkdir dir="${build}" />
  <mkdir dir="${packaging}" />
 </target>
 <!--
 =============================================================================================
 컴파일
 =============================================================================================
 -->
 <!-- 소스 컴파일 -->
 <target name="compile"  >
  <javac srcdir="${src}" destdir="${build}">
   <classpath>
    <path refid="cactus.classpath"/>
    <pathelement location="${servletapi.jar}"/>
   </classpath>
  </javac>
 </target>
 <!--
 =============================================================================================
 패키징
 ${build}에 생성된 클래스들과, ${conf}에 있는 web.xml 설정 정보를 모아서 하나의 WAR파일로 패키징 한다.
 =============================================================================================
 -->
 <!-- WAR 패키징 -->
 <target name="packaging" depends="compile" >
  <war warfile="${packaging}/${project.name}.war"  webxml="${conf}/web.xml" >
   <classes dir="${build}" />
   <lib dir="${lib}"/>
  </war>
 </target>
 
 <!--
 =============================================================================================
 배포
 LOCAL Machine으로 배포하는 스크립트로 tomcat의 /webapps 디렉토리에 war파일을 복사한다.
 =============================================================================================
 -->
 <!-- 배포 -->
 <target name="deploy" depends="packaging" >
  <copy file="${packaging}/${project.name}.war" todir="${tomcat.home}/webapps"/>
 </target>
 
 <!--
 =============================================================================================
 테스트
 =============================================================================================
 -->  
 <!-- Cactus 테스트 -->
 <target name="cactus-test">
   <!-- Run the tests -->
    <cactus  warfile="${packaging}/${project.name}.war" fork="yes"
     printsummary="yes"
        failureproperty="tests.failed">
   <classpath>
    <path refid="cactus.classpath"/>
    <pathelement location="${servletapi.jar}"/>
    <pathelement location="${build}"/>
   </classpath>
      <containerset>
       <!--
       <tomcat5x dir="D:\dev\apache-tomcat-5.5.23" port="8080" />
        -->
       <generic name="local tomcat" port="8080">
            <startup target="dummy"/>
            <shutdown target="dummy"/>
       </generic>
   
      </containerset>

      <formatter type="brief" usefile="false"/>
      <formatter type="xml"/>
      <batchtest todir="${cactus.testlog}">
        <fileset dir="./src">
          <include name="**/Test*.java"/>
        </fileset>
      </batchtest>
    </cactus>
    <!-- JUnit(cactus) 테스트 리포트 생성 -->
    <junitreport todir="${cactus.testlog}">
   <fileset dir="${cactus.testlog}" includes="TEST*.xml"/>
     <report todir="${cactus.testlog}" format="frames"/>
    </junitreport>
     
    <fail if="tests.failed"> cactus Test failed</fail>
 </target>
 <target name="dummy">
 </target>
 
 
</project>
   

'ALM > Test Automation' 카테고리의 다른 글

단위 테스트 1회 (JUnit)  (1) 2007.11.23
Test Coverage 분석툴  (0) 2007.11.08
Cactus 실행용 ANT 스크립트  (0) 2007.09.13
Cactus 빌드 스크립트 샘플  (0) 2007.09.12
Unit Testing WebLogic Workshop 8.1 Applications & JWebUnit  (0) 2007.08.27
JUnitEE vs Catcus  (0) 2007.08.27
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.
TAG ant, Cactus

댓글을 달아 주세요

Cactus 빌드 스크립트 샘플

ALM/Test Automation | 2007.09.12 18:53 | Posted by 조대협
http://fisheye.codehaus.org/browse/controlhaus/jdbc/trunk/test/container/build.xml?r=337

BEA에서 JDBC Control 만들어서 Apache에 기증한 것 같은데. Build 스크립트에서 Cactus 테스트 및 JUnit 리포트를 생성한다. Clover로 테스트 커버리지 분석도 하고..
상당히 유용한 빌드 스크립트인듯

'ALM > Test Automation' 카테고리의 다른 글

Test Coverage 분석툴  (0) 2007.11.08
Cactus 실행용 ANT 스크립트  (0) 2007.09.13
Cactus 빌드 스크립트 샘플  (0) 2007.09.12
Unit Testing WebLogic Workshop 8.1 Applications & JWebUnit  (0) 2007.08.27
JUnitEE vs Catcus  (0) 2007.08.27
DBUnit 예제  (1) 2007.08.27
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요


JCS,JPF,JCX등에 대한 테스트 방법
http://dev2dev.bea.com/pub/a/2004/12/eckels_BP.html

아래는 JWebUnit이다. HttpUnit의 확장판인데. 특히나
assert 메서드들이 흥미롭다.
예를 들어
assertTextPresent("Hello World!");
assertTextInElement("attributeOne", pretendObject.getAttributeOne());
위의 둘처럼 response HTML을 모두 무식(?)하게 테스트 하는 것이 아니라 어떤 Text가 있는지, 내지는 Element내에 있는 Text를 검색함으로써 좀더 resonable한 테스트가 가능하다.
통채로 HttpResponse를 테스트 한다면, 디자인이 (CSS,Javascript,HTML등등)이 변경이 되면 테스트도 깨질 수 있는데, 특정 텍스트 검색등은 실제 비지니스 로직과 관련이 되기 때문에 이 데이타만 비교한다면, 디자인에 무관하게 View단 (JSP,Servlet)에 대한 테스트가 가능할것 같다.
물론 서버쪽과의 통신은 Catcus나, JUnitEE등을 사용해야겠지만..

강좌 문서 : http://today.java.net/pub/a/today/2007/04/12/embedded-integration-testing-of-web-applications.html
JWebTest URL : http://jwebunit.sourceforge.net/articles.html
한글 문서 : http://tong.nate.com/ggypsy/20308320

단위 테스트 관련 자료를 찾아보니, Catcus는 국내 자료는 거의 없고, 생각보다 JWebUnit에 대한 자료는 많이 찾을 수 있었다. 단위 테스트에서 실제 UI단까지 테스트 하는것이 옳은지는 모르겠지만, 많이들 사용하는것을 봐서는 한번쯤 주먹해볼 필요가 있을듯.

'ALM > Test Automation' 카테고리의 다른 글

Cactus 실행용 ANT 스크립트  (0) 2007.09.13
Cactus 빌드 스크립트 샘플  (0) 2007.09.12
Unit Testing WebLogic Workshop 8.1 Applications & JWebUnit  (0) 2007.08.27
JUnitEE vs Catcus  (0) 2007.08.27
DBUnit 예제  (1) 2007.08.27
단위 성능 테스트  (0) 2007.08.24
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

JUnitEE vs Catcus

ALM/Test Automation | 2007.08.27 22:45 | Posted by 조대협
JUnitEE is a much simpler framework than Cactus, and provides a mechanism with which to invoke regular JUnit tests inside the container. You write your JUnit tests as normal and deploy them along with your application. You then (from your browser) request a predefined Servlet and tell it which JUnit tests to run. The results are then presented to you in a readble HTML form.

Cactus on the other hand is a much more complex beast and provides you with a ready-made set of classes from which you can write tests for Servlets, JSPs, taglibs and EJBs.

With JUnitEE, writing standard JUnit tests doesn't provide you with easy access to the environment, meaning that you can't easily run assertions on things like the current ServletRequest, response, etc. The classes (test cases) that you extend in Cactus provide you with wrappers to the actual objects that are currently "live" within the server. In other words, you can actually get access to things like the current ServletRequest and run assertions against it.

<shameless plug>
The thing that I don't like about Cactus is its support for testing JSP custom tags as you have to test them by writing the code to mimic the way that the JSP container uses them. If you need to test custom tags, check out TagUnit for an alternative that allows you to write tests within JSP.
</shameless plug>

Cheers
Simon
==
정리하자면, JUnitEE는 JUnit테스트를 단순하게, Server container안에서 동작하게 해주는것이고, Catcus는 JSP,TagLib,Servlet,EJB에 대한 좀더 구체적인 테스트 프레임웍을 제공한다. (HTTP로 Request를 넣어서 Response를 받는것은 HttpUnit을 사용해야 한다.)

'ALM > Test Automation' 카테고리의 다른 글

Cactus 빌드 스크립트 샘플  (0) 2007.09.12
Unit Testing WebLogic Workshop 8.1 Applications & JWebUnit  (0) 2007.08.27
JUnitEE vs Catcus  (0) 2007.08.27
DBUnit 예제  (1) 2007.08.27
단위 성능 테스트  (0) 2007.08.24
단위 테스트 방법  (0) 2007.08.24
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

DBUnit 예제

ALM/Test Automation | 2007.08.27 16:50 | Posted by 조대협

데이타베이스에 대한 테스트를 할 수 있는 DBUnit에 대한 샘플 코드.
DBUnit은 DataBaseConnection을 JDBCDriver,JNDI,DataSource등에서 얻어올 수 있다. 아래 예제는 JDBCDriver에서 얻어오는 예제

테스트 절차는 다음과 같다.
1) setUp메서드에서 데이타베이스를 테스트전으로 초기화 하고, (이때, XML파일을 이용해서 초기 데이타를 로딩할 수 있다.)
2) 테스트할 OBJECT를 수행한후
3) 테스트 기대 결과를XML에서 읽은후에
4) 데이타베이스의 기록 상태를 3)과 비교한다.

참고로 1)의 데이타는 테스트케이스에서 자동으로 XML 파일로Generation하거나 DTD를 생성할 수 있다.

참고 : http://www.onjava.com/pub/a/onjava/2004/01/21/dbunit.html

== EmpDAOTest .java ==
package bcho.simpledb.test;

import java.io.File;
import java.io.FileInputStream;
import java.sql.Connection;
import java.sql.DriverManager;

import org.dbunit.Assertion;
import org.dbunit.DBTestCase;
import org.dbunit.PropertiesBasedJdbcDatabaseTester;
import org.dbunit.database.DatabaseConnection;
import org.dbunit.database.IDatabaseConnection;
import org.dbunit.dataset.IDataSet;
import org.dbunit.dataset.ITable;
import org.dbunit.dataset.xml.FlatXmlDataSet;
import org.dbunit.operation.DatabaseOperation;

import bcho.simpledb.EmpDAO;
import bcho.simpledb.EmpDAOImpl;

public class EmpDAOTest extends DBTestCase
{
 final static String JDBC_DRIVER="org.gjt.mm.mysql.Driver";
 final static String JDBC_USERID="irteam";
 final static String JDBC_USERPASSWD="svnirteam";
 final static String JDBC_URL="jdbc:mysql://121.156.62.202:20001/db_svn_auth";
 //
 // Method Overloading
 //


 protected IDataSet getDataSet() throws Exception
 {
  return new FlatXmlDataSet(new FileInputStream("c:\\temp\\dataset.xml"));
 }
 
 public EmpDAOTest(String name){
  super(name);
     System.setProperty( PropertiesBasedJdbcDatabaseTester.DBUNIT_DRIVER_CLASS, JDBC_DRIVER );
     System.setProperty( PropertiesBasedJdbcDatabaseTester.DBUNIT_CONNECTION_URL, JDBC_URL );
     System.setProperty( PropertiesBasedJdbcDatabaseTester.DBUNIT_USERNAME, JDBC_USERID );
     System.setProperty( PropertiesBasedJdbcDatabaseTester.DBUNIT_PASSWORD, JDBC_USERPASSWD );

 }

    protected DatabaseOperation getSetUpOperation() throws Exception
    {
        return DatabaseOperation.DELETE_ALL;
    }
    protected DatabaseOperation getTearDownOperation() throws Exception
    {
        return DatabaseOperation.NONE;
    }

 //
 // Test Method
 //

 public void testInsertEmployee(){
  IDatabaseConnection conn = null;
  try{
   // execute Test Object
   EmpDAO empDao = new EmpDAOImpl();
   empDao.insertEmployee("bcho", "YoungIn Suji");
   
   // fetch Data After insert
   conn = getConnection();
   IDataSet databaseDataSet = conn.createDataSet();
   ITable actualTable = databaseDataSet.getTable("BCHO_EMP");
   
   // fetch Data from XML data sheet
   IDataSet expectedDataSet = new FlatXmlDataSet(new File("c:\\temp\\dataset.xml"));
   ITable expectedTable = expectedDataSet.getTable("BCHO_EMP");
   Assertion.assertEquals(expectedTable,actualTable);
  }catch(Exception e ){
   e.printStackTrace();
   fail("Test failed during testEmpTable");
  }finally{
   try{
    closeConnection(conn);
   }catch(Exception e){
    fail("Fail to close connection");
   }//try-catch
  }//finally
 
 }
}
=== dataset.xml ==
<?xml version='1.0' encoding='euc-kr'?>

<dataset>
 <BCHO_EMP name='bcho'
    address='Seoul Korea'/>
</dataset>
===

'ALM > Test Automation' 카테고리의 다른 글

Unit Testing WebLogic Workshop 8.1 Applications & JWebUnit  (0) 2007.08.27
JUnitEE vs Catcus  (0) 2007.08.27
DBUnit 예제  (1) 2007.08.27
단위 성능 테스트  (0) 2007.08.24
단위 테스트 방법  (0) 2007.08.24
테스트의 종류  (0) 2007.08.24
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.
TAG DBUnit

댓글을 달아 주세요

  1. 신지훈 2016.03.24 13:52  댓글주소  수정/삭제  댓글쓰기

    DBUnit를 통해서 디비 서버에 있는 값을 가지고 오는 방법은 없나요???
    현재 서버의 데이터 값과 JSP에서 보여주는 차트 등의 값이 같은지를 판단하고 싶은데 찾기가 어렵네요 ㅠㅠㅠ
    그게 아니라면 지금 가지고 있는 CSV파일의 값과 디비 서버이 값이 같은지 판단하는 테스팅 방법이라든가...

    보통 데이터 조회 테스팅은 어떻게 이루어 지는 건가요??

단위 성능 테스트

ALM/Test Automation | 2007.08.24 15:13 | Posted by 조대협
성능 테스트 역시 매우 중요한데,
성능 테스트는 외부적인 요인 (하드웨어 성능, DBMS의 정렬 상태, 네트워크 상태, 다른 AP에 의한 CPU 사용률의 차이)로 인해서 사실 정확한 측정을 하기란 어렵다.

JUnit에서 Timer 객체를 이용해서, elapsed time을 측정할 수 도 있지만.
JUnit의 확장으로 성능 테스팅을 할 수 있는 것이 http://www.clarkware.com/software/JUnitPerf.html 있다.

'ALM > Test Automation' 카테고리의 다른 글

JUnitEE vs Catcus  (0) 2007.08.27
DBUnit 예제  (1) 2007.08.27
단위 성능 테스트  (0) 2007.08.24
단위 테스트 방법  (0) 2007.08.24
테스트의 종류  (0) 2007.08.24
DbUnit  (0) 2007.08.24
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

단위 테스트 방법

ALM/Test Automation | 2007.08.24 14:26 | Posted by 조대협
단위 테스트 방법중에서.
특히나 J2EE의 경우에는 컨테이너를 필요로 한다.
컨테이너가 없다면 EJB나 JSP등은 구동조차 하지 않을테니까는.
이를 위한 테스트 방법이 2가지가 있는데,

○ Mock test
○ In-container test

 
두가지이다.
Mock Test는 Container를 시뮬레이션 하는 테스트이고, In container test는 실제 컨테이너에서 테스트 하는 방법으로 JUnit을 확장한 Catcus라는 테스트 프레임웍을 사용하면된다.

Apache에서 제공하는 Catcus 테스트는 크게, Servlet,JSP,Filter,Tag Lib, Struts등의 테스트가 가능하고, 자세한 정보는 http://www.apache-korea.org/cactus/writing/howto_jsp.html 를 참고하도록 한다.

Java 환경을 위한 MockTest 는 www.mockobjects.com의 프레임웍을 이용하도록한다.
(cf. www.easymock.org )

==
WLI의 BPM 테스트를 위한 프레임웍
https://jprocessunit.projects.dev2dev.bea.com/


'ALM > Test Automation' 카테고리의 다른 글

DBUnit 예제  (1) 2007.08.27
단위 성능 테스트  (0) 2007.08.24
단위 테스트 방법  (0) 2007.08.24
테스트의 종류  (0) 2007.08.24
DbUnit  (0) 2007.08.24
JUnit 사용법  (0) 2007.07.25
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

테스트의 종류

ALM/Test Automation | 2007.08.24 11:57 | Posted by 조대협
여러 분류가 있겠지만

○ 단위 테스트 (Unit Test)
단위 컴포넌트의 기능이 잘 수행되는지만 체크한다.
프로그래머가 기대한데로, 단위 컴포넌트가 제대로 작동하는지만 체크할 뿐, 그것이 성능이나 장애에 대한 대처 능력이 있는지 또는 고객의 요구 사항에 부합하는지와는 상관 없이 컴포넌트 자체만 테스트한다.

○ 통합 테스트 (Integration Test)

○ 수락 테스트 (Acceptance Test)
고객의 요구 사항에 부합하는지에 대한 테스트를 수행한다.
기능 테스트는 당연하고, 성능 테스트 (Performance Test), 장애 테스트 (Failure Test) 등을 수행하게 된다.

'ALM > Test Automation' 카테고리의 다른 글

DBUnit 예제  (1) 2007.08.27
단위 성능 테스트  (0) 2007.08.24
단위 테스트 방법  (0) 2007.08.24
테스트의 종류  (0) 2007.08.24
DbUnit  (0) 2007.08.24
JUnit 사용법  (0) 2007.07.25
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.
TAG 테스트

댓글을 달아 주세요

하나의 소스를 가지고 개발 환경, 테스트 환경, QA환경, 운영 환경에 DEPLOY할때,
이를 자동화 할 필요성이 있다.

ANT에 PROPERTY파일을 가지고 진행이 가능한데.
http://www.pragmaticautomation.com/cgi-bin/pragauto.cgi/Deploy/ManyDeploymentEnvironments.rdoc

설명이 나와있다.

'ALM > Build Automation (빌드 자동화)' 카테고리의 다른 글

이제는 Trac  (1) 2008.01.24
Hudson  (0) 2008.01.22
Atlassian Bamboo  (0) 2007.11.08
일일 빌드에 대해서..  (0) 2007.10.17
하나의 소스를 여러 환경에 DEPLOY하는 방법  (0) 2007.08.24
SVN CheckOut and Build 자동화 스크립트 예제  (0) 2007.08.23
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.
TAG ant, deploy

댓글을 달아 주세요

DbUnit

ALM/Test Automation | 2007.08.24 10:55 | Posted by 조대협
JUnit의 확장판으로
데이타베이스에 대한 테스트를 자동화할 수 있게 해준다.
대부분의 Web App가 RDBMS인것을 가만한다면,
꼭 필요하지 않을까?

==
http://dbunit.sourceforge.net/
==

'ALM > Test Automation' 카테고리의 다른 글

DBUnit 예제  (1) 2007.08.27
단위 성능 테스트  (0) 2007.08.24
단위 테스트 방법  (0) 2007.08.24
테스트의 종류  (0) 2007.08.24
DbUnit  (0) 2007.08.24
JUnit 사용법  (0) 2007.07.25
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.
TAG DBUnit, junit

댓글을 달아 주세요


SVN에서 자동으로 Checkout해서 Build하는 과정까지 자동화
==
<project name="helloworld" default="build" basedir="./">
<taskdef name="svn" classname="org.tigris.subversion.svnant.SvnTask"/>
 <target name="prepare">
  <delete dir="checkout"/>
  <mkdir dir="checkout"/>
 </target>
 <target name="checkout" depends="prepare">
  <svn username="KR12935" password="passwd">
   <checkout
    url="http://url/svn/HelloWorld/HelloWorld/trunk"
    destPath="./checkout"/>
  </svn>
 </target>
 <target name="build"  depends="checkout">
  <ant dir="checkout" antfile="build.xml" />
  </target>
</project>
==

이 스크립트는 Cruise Control의 LOCAL환경에 설정을하고
실제 build.xml은 SVN안의 프로젝트(컴포넌트)안에 위치 시켜서 Build 스크립트까지 다운 로드 받도록 한다.

'ALM > Build Automation (빌드 자동화)' 카테고리의 다른 글

이제는 Trac  (1) 2008.01.24
Hudson  (0) 2008.01.22
Atlassian Bamboo  (0) 2007.11.08
일일 빌드에 대해서..  (0) 2007.10.17
하나의 소스를 여러 환경에 DEPLOY하는 방법  (0) 2007.08.24
SVN CheckOut and Build 자동화 스크립트 예제  (0) 2007.08.23
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

JUnit 사용법

ALM/Test Automation | 2007.07.25 12:46 | Posted by 조대협
http://blog.naver.com/goethe1004?Redirect=Log&logNo=80034140150
퍼온글.

'ALM > Test Automation' 카테고리의 다른 글

DBUnit 예제  (1) 2007.08.27
단위 성능 테스트  (0) 2007.08.24
단위 테스트 방법  (0) 2007.08.24
테스트의 종류  (0) 2007.08.24
DbUnit  (0) 2007.08.24
JUnit 사용법  (0) 2007.07.25
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.
TAG eclipse, junit

댓글을 달아 주세요