1장. 테스트 주도 개발

테스트 주도 개발의 진행 방식

1. 질문(ASK) : 테스트 작성을 통해 시스템에 질문한다.( 테스트 수행 결과는 실패)

2. 응답(RESPONSE) : 테스트를 통과하는 코드를 작성해서 질문에 대답한다. ( 테스트 성공)

3. 정제(REFINE) : 아이디어를 통합하고, 불필요한 것은 제거하고, 모호한 것은 명확히 해서 대답을 정제한다. (리팩토링)

4. 반복(REPEAT): 다음 질문을 통해 대화를 계속 진행한다.

^[각주:1]

" 목표를 먼저 세운다 -> 자동화된 테스트케이스를 작성한다. -> 만족시키는 로직을 작성하고 정련한다. "

질문 단계

작성하고자 하는 메소드나 기능이 무엇이지 선별하고 작성 완료 조건을 정해서 실패하는 테스트 케이스를 작성하는 것

클래스 스켈레톤(skeleton) 구현 : 메소드 외양 부터 만드는것 && 리턴 타입은 기본 초기값(null, 0 등) 위주로 설정하면 편함

☆ 설계없이 시작할땐, 구현해야 하는 기능과 유의사항을 생각는대로 적기.

테스트 케이스 작성법 

1. 구현 대상 클래스의 외형에 해당하는 메소드들을 먼저 만들고 테스트 케이스를 일괄적으로 만드는 방식

2. 테스트 케이스를 하나씩 추가해나가면서 구현 클래스를 점진적으로 만드는 방식

여기선 주로 2번을 씁니다.!

테스트 케이스는 하나의 메소드로 표현한다. 

테스트 케이스를 만들면서 컴파일에러가 나는 것은 당연한데 테스트 시나리오를 코드로 기술하는 작업을 마치고, 해결하는 것이 좋다. 왜냐하면 테스트 케이스를 작성시 흐름을 잃지 않기 위해서다. 

응답단계

테스트 케이스를 통과하는 코드를 작성한다.

정제단계

리팩토링을 적용할 부분이 있는지 찾아본다.

ToDo 목록에서 완료된 부분을 지운다. 

해 볼 질문:     

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

2. 중복된 코드는 없는가?

3. 이름이 잘못 부여된 메소드나 변수명은 없는가?

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

클래스 설계시

속성을 고민하지 말고, 동작을 고민하자.

클래스에서 중요한 것은 동작! 동작을 먼저 정하고, 그 동작에 필요한 속성을 고려한다는 식으로 접근하자. 

※ JUnit 결과에서 error와 failures의 차이

error : 작성자가 의도하지 않은 예상치 못한 실패, 이 경우에는 테스트케이스 자체에 문제가 있다는 뜻.

failures : 테스트 케이스를 만족하지 못했다는 것. 이 경우에는 테스트케이스는 정상적으로 동작했지만, 기대하는 값이 다르게 나온 것.

Eclips 단축키

1. Alt + ← : 지금 java 파일 바로 전에 건드린 java파일로 이동해 준다. java파일을 순서대로 이동합니다.(Alt + → 도 사용가능.)

2. Ctrl + Shift + O : import할 클래스을 자동으로 정리해준다. or Quick Fix의 1번.

3. Alt + Shift + R : Rename기능. 

4. Ctrl + D : 한줄 라인 지우기.

Quick Fix 기능

1. Ctrl + 1  : 

create class (에러가 나는 부분에 대고 눌러보아요) , 

add JUnit 4 library to the build path를 누르면 됩니다. 

생성자에서 파라메터에 놓고, 누르면 Assign Parameter to in new field가 나온다. 그러면 자동으로 필드와 필드에 값넣는 것 까지 해준다.

엉클 밥의 TDD원칙(로버트 마틴)

1. 실패하는 테스트를 작성하기 전에는 절대로 제품 코드를 작성하지 않는다.

2. 실패하는 테스트 코드를 한번에 하나 이상 작성하지 않는다. 

3. 현재 실패하고 있는 테스트를 한 번에 통과하기에 충분한 정도를 넘어서는 제품 코드를 작성하지 않는다.

 

1. http://upload.wikimedia.org/wikipedia/en/9/9c/Test-driven_development.PNG [본문으로]