[TDD/테스트주도개발] TDD 개념

테스트 주도 개발 TDD 실천법과 도구 정리한 내용입니다. 해당 내용은 Junit4 버전을 기준으로 설명합니다.
책이 절판됨에 따라 저자인 채수원님께서 무료로 PDF를 공개하셨으니 블로그에서 관련 자료 다운로드가 가능합니다.
또한 책이 2010년에 출간되었다는 점에서 저자분이 해당 내용에 보충할 만한 내용도 같이 정리해서 올려주시니 관련 링크를 통해서 참고하시는게 제일 좋은 방법일 것 같습니다.

https://repo.yona.io/doortts/blog/issue/1

목차

---

1. 테스트 주도 개발
2. JUnit과 Hamcrest
3. TDD 좀 더 잘하기
4. 한계 돌파를 위한 노력, Mock을 이용한 TDD
5. 데이터베이스 테스트 : DbUnit
6. 단위 테스트 지원 라이브러리 : Unitils
7. 개발 영역에 따른 TDD 작성 패턴
8. TDD에 대한 다양한 시작
9. 자주 접하게 되는 질문들, FAQ
10. 실습 예제
11. 테스트 자동화와 커버리지
12. 부록

1. 테스트 주도 개발

1-1. TDD란?

---

Test Driven Development의 약자로 말 그대로 테스트 주도 개발이라는 언어입니다.
즉 기존의 SW를 개발하고 테스트를 하는 방식이 아닌, 테스트부터 작성하면서 코드를 작성하는 방법을 말합니다.

1-2. TDD 개발의 진행 방식

---

해당 책에서는 TDD를 크게 3가지의 단계가 반복적으로 이루어진다고 설명하고 있습니다.

* 질문 : 테스트 작성을 통해 시스템에 질문 ( 테스트 실패 )  
* 응답 : 테스트를 통과하는 코드를 작성해서 질문에 대답한다 ( 테스트 성공 )
* 정체 : 통합, 불필요한 부분 제거 등의 리팩토링
* 반복 : 위 3가지를 반복을 통해 계속 작성해 나간다.

1-3. TDD의 간단한 실습 예제

---

아래와 같은 테스트가 필요하다고 정의합니다.

1. Member 클래스 필요
2. Member의 기능
    * ID 받아오기
    * 비밀번호 암호화하기
    * 기타등등..
3. 기타 등..

최초로 프로젝트를 생성 후, 임시로 Test 클래스를 하나 작성해봅니다. 그리고 annotation으로 @Test를 선언해주고 메소드를 하나 만들어줍니다. 그 후 아래와 같은 질문을 통해서 테스트 케이스를 작성합니다.

public class TestAccount() {
    @Teest
    public void testMember() {
           Member member = new Member();
    }
}

위와같이 작성 후 JUnit4으로 실행을 합니다. Membmer 클래스가 정의되어 있지 않은 상태에서 인스턴스화 하려고 하니 당연히 오류가 발생합니다. 이 단계가 질문에 해당합니다.
  이제 응답 단계입니다. 어려울거 없이 Member클래스를 생성해주면 그만입니다. 그리고 임의의 요구에 따라서 null이면 안되는 객체이기 때문에 조건을 추가해줍니다.

public class TestAccount {
    @Test
    public void testMember() throws Exception {
        Member member = new Member();
        if(member == null) {
            throw new Exception("member 생성 실패!");
        }
        // 또는
        assertNotNull(member);
    }
}

마지막으로 정제(리팩토링) 단계입니다. 통상적으로 아래와 같은 고민 후 소스를 리팩토링해줍니다.

• 소스의 가독성이 적절한가?
• 중복된 코드는 없는가?
• 이름이 잘못 부여된 메소드나 변수명은 없는가?
• 구조의 개선이 필요한 부분은 없는가?

자 이제 저희는 위 예제에서 개선이 필요한 부분은 없는가? 에서 한가지 제거할 코드가 존재합니다.
사실 new 연산자를 통해 인스턴스 생성 시 오류가 발생하면 자동으로 Exception이 발생하고, 그 상황을 JUnit가 처리하기 때문에 null인지 체크하는 부분은 더 이상 필요가 없어집니다.

public class TestAccount {
    @Test
    public void testMember() throws Exception {
        Member member = new Member();
    }
}

여기까지가 질문 1인 Member 클래스 검증 부분을 끝마쳤습니다. 사실 예제가 간단해서 억지스러운 부분도 존재하지만, TDD를 어떤식으로 진행하는지에 대한 감익히기가 목표이기 때문에 전체적은 느낌을 이해하셨다면 성공이라고 생각합니다.

1-4. TDD 장점

---

• 개발의 방향을 잃지 않게 유지해준다.
• 품질 높은 소프트웨어 모듈 보유, 시스템 결함이 줄어든다.
• 자동화된 단위 테스트 케이스를 갖게 된다. 유지보수 용이
• 사용설명서 & 의사소통의 수단, 테스트 문서로 사용 가능
• 설계 개선. 필자가 제일 강조하며, 본인이 얼마나 의존적이고 즉흥적인 설계를 하고 있는지 체감할 수 있다고 한다...
• TDD는 주기를 짧게 설정하도록 권장해서, 성공했다는 성취감을 얻음으로써 능률을 향상 시킨다.

1-5. 엉클 밥의 TDD 원칙

---

엉클 밥은 로버트 마틴(Robert C. Martin)으로 객체 지향 개발의 선구자로 유명하다. 이 분이 권장하는 TDD의 원칙 3가지를 소개합니다.

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

3번은 의외인것 같다. 추후 사용해보면서 체감을 할 수 있기를 바라면서