[소프트웨어 공학] TDD (Test Driven Development)

 

XP의 창시자 켄트 백의 TDD

 

TDD란 도대체 무엇일까?

어떤 의미를 가진 약자일까?

도대체 이게 개발하고 무슨 관련이 있는 것일까?

 

XP(eXtreme Programming) 창시자 중 한명이자, TDD를 주도한 켄트 백은 TDD를 소개한 자신의 책에서 "프로그램을 작성하기 전에 테스트를 먼저 작성하는 것"이라고 테스트 주도개발을 정의하였습니다. 프로그램을 작성하지도 않았는데, 테스트를 먼저 하라는 것은 무슨 의미인지 어리둥절했습니다.

 

 

"프로그램을 작성하기 전에 테스트를 먼저 하라! Test the program before you write it! " by 켄트 백

 

 

---

 

"업무 코드를 작성하기 전에 테스트 코드를 먼저 만드는 것"

 

 

 

코드를 검증하는 테스트 코드를 먼저 만든 다음에 실제 작성해야 하는 프로그램 코드작성에 들어가라는 뜻입니다. 최초에는 테스트 우선 개발 (Test First Development)이라고 불렸으나 지금은 테스트 주도 개발 (Test-Driven Development, TDD)이라 불립니다. 테스트 코드를 작성한다는 TDD의 정의가 다소 과격하게 들릴 수도 있지만, 메소드나 함수 같은 프로그램 모듈을 작성할 때 '작성 종료조건을 먼저 정해놓고 코딩을 시작한다'는 의미로 받아들이면 편합니다.

 

예를 들어, 2개의 숫자 합을 구해서 반환하는 SUM이라는 메소드를 작성한다고 가정해봅시다.

 

 

 

 

위의 표는 만들고자 하는 메소드를 일종의 설계문서(Spec)처럼 간단히 적어본 모습입니다. 사실 이러한 형식은 굳이 TDD라는 용어를 꺼내지 않더라도, 우리가 프로그램을 작성할 때 머릿속으로 생각하는 내용과 별반 다르지 않습니다.

 

다만 '문서로 만들어 머리로 생각하고 눈으로 확인할 것인가?' 아니면 '예상결과를 코드로 표현해놓고 해당 코드가 자동으로 판단하게 할 것인가?' 의 차이가 있습니다. 예를 들면 위의 설계 문서에 따라 sum 메소드를 작성할 때, 코드를 정상적으로 구현됐는지를 판단하는 방법을 선택한다면 아래와 같은 코드로도 작업할 수 있습니다.

 

 

 

 

위의 예제는 main 메소드를 테스트 메소드 처럼 사용했습니다. sum 메소드는 컴파일 에러만 나지 않도록 해놓고, 내부는 비어 있는 상태입니다. sum 메소드를 먼저 구현한 다음에 테스트를 할 수도 있지만, 그렇게 하지 않고 검증코드를 먼저 만들어놓았습니다. 그 검증코드에 해당되는 테스트 케이스를 모두 만족하면, 즉 main 메소드의 실행 결과가 모두 true로 나오면 sum 메소드가 정상적으로 작성됐다고 판단하기로 한 것입니다.

 

명시적인 코드로 개발 종료조건을 정해놓은 것입니다. 이런 식의 개발 접근 방식이 바로 TDD입니다. 무언가 특별한 테크닉이나 테스트 프레임워크를 써야 TDD일 것 같지만 그렇지 않습니다. 테스트 케이스 작성으로 구현을 시작하는 것, 그게 바로 TDD방식입니다.

 

---

 

이 포스트는 학부에서 제공하는 기본적인 컴퓨터, 소프트웨어 공학 강의와 책들을 토대로 알기 쉽게 내용을 작성하였습니다. 하지만 계속 더 유익하고 논문 및 전문 서적을 읽어가며 더 추가돼야 할 내용이 있으면 컴퓨터, 소프트웨어 공학, 프로그래밍 포스트와 콘텐츠들을 계속 고도화하는 방식으로 진행하려고 합니다.

 

#컴퓨터공학 #소프트웨어공학 #프로그래밍 #공대공부 #TDD #테스트주도개발 #개발방법론