테스트 (Test)

(1)개발자 테스트, 단위 테스트

(2)테스트의 문제점

1) 특정 모듈의 개발기간이 길어질수록 개발자의 목표의식이 흐려진다.

2) 작업 분량이 늘어날 수록 확인이 어려워진다.

3) 코드의 사용방법과 변경이력을 개발자의 기억력에 의존하게 되는 경우가 많다.

4) 테스트값 입력시 점점 간소화 된다.

5) 코드 수정시 기존코드의 정상동작에 대한 보장이 없다.

- 회귀 테스트

6) 테스트 할 준비사항이 너무 많아진다.


(3) TDD

1) Test the program before you write it. - kent beck

2) 최종 목표

clean code that works - Ron Jeffries

3) 진행 방식

질문 -> 응답 -> 정제 -> 반복

4) 실습 시나리오

--------------------------------------

- 기본 시나리오

은행 계좌 클래스

계좌 잔고 조회

입금/출금

...

- 첫번째 질문

계좌가 생성되었는가?

class name : Account

function :

- 잔고 조회

- 입금

- 출금

dest : 금액은 원 단위(예: 천원 = 1000)


- 첫번째 응답

계좌 생성 메서드 구현


- 첫번째 정제

소스의 가독성이 적절한가?

중복된 코드는 없는가?

이름이 잘못 부여된 메서드나 변수는 없는가?

구조의 개선이 필요한 부분은 없는가?

...


jUnit

1) 3.X : Inheritance

2) 4.X : Annotation

- 두번째 질문

잔고 조회가 되는가?

1000원으로 계좌를 생성

잔고 조회 결과가 일치


- 두번째 응답

잔고 조회 기능 구현


- 두번째 정제

i -> money


- 세번째 질문

입/출금 기능이 되는가?


- 세번째 정제

i -> money


3) 3.x : 2개의 규칙과 4개의 구성요소

- 규칙

TestCase를 상속 받는다.

테스트 메서드의 이름은 반드시 test로 시작

- 구성요소

a) 테스트 픽스쳐 메서드

setUp(), tearDrop()


public class DaoTest extends TestCase {

Connection con;


protected void setUp() throws Exception {

// DB 연결

con = getConnection();

}


public void testA() throws Exception {

...

}


public void testB() throws Exception {

...

}


protected void tearDrop() throws Exception {

// DB연결 해제

}

}


setUp() -> testA() -> tearDrop()

setUp() -> testB() -> tearDrop()


b) 단정문

assertEquals([message], expected, actual)

assertTrue([message], expected)

assertFalse([message], expected)

assertNull([message], expected)

assertNotNull([message], expected)

assertSame([message], expected, actual)

assertNotSame([message], expected, actual)

assertThat([message], expected, actual)

fail([message])

c) 테스트 러너

d) Test Suite


*. 테스트 픽스쳐

일관된 테스트 실행 환경을 의미.

다른말로 테스트 컨텍스트라고도 한다.


4) 4.x

- test라는 글자로 method이름을 시작해야 한다는 제약이 없어졌다. 

  @Test를 붙이면 된다.


- 좀 더 유역한 픽스쳐

@BeforeClass

@AfterClass

@Before

@After


public class DaoTest extends TestCase {

Connection con;


@BeforeClass

protected void init() throws Exception {

...

}

protected void destroy() throws Exception {

...

}


@Before

protected void setUp() throws Exception {

// DB 연결

con = getConnection();

}


public void testA() throws Exception {

...

}


public void testB() throws Exception {

...

}

@After

protected void tearDrop() throws Exception {

// DB연결 해제

}

}


init()

setUp() -> testA() -> tearDrop()

setUp() -> testB() -> tearDrop()

destroy()


- 추가된 단정문

@Test(expected=NumberFormatException.class)


@Test(timeout=1000)


@Ignore @Test


assertArrayEquals([message], expected, actual)

...



'BACKEND > Spring' 카테고리의 다른 글

[Spring] 스프링 시작시점에서 프로그램 동작할 수 있게 하는 방법  (0) 2018.11.15
Secure Coding  (0) 2018.03.05
Spring  (0) 2018.02.05
[Spring] Spring Security  (0) 2017.06.26
[Spring] Tiles  (0) 2017.06.23

댓글

Designed by JB FACTORY