STG / 황성원

Test-Driven Development

TDD

1. TDD(Test-Driven Development) 란 ?

2. TDD 개발법3. TDD 의 장점4. TDD 의 한계

TDD

TDD 란 ?

4

01

TDD 목적 또한 개발 된 소프트웨어의 품질을 보장하고 향상시키는 데 있다 .

TDD 의 목표는 작동하는 깔끔한 코드 “ Clean code that works” 이다 .

이를 위해 두 가지 원칙을 제시한다 .

• 오직 자동화된 테스트가 실패할 경우에만 새로운 코드를 작성한다• 중복을 제거한다 .

일반적인 개발 절차는 다음과 같이 진행 되어 왔다 .

• 요구사항 분석 -> 설계 -> 개발 -> 테스트 -> 배포 기존 개발법엔 소프트웨어 개발을 느리게 하는 잠재적 위험들이 존재한다

- 소비자의 요구사항의 불 명확성- 완벽한 설계에 대한 부담- 실제 코드와 설계간의 갈등- 수정이 다른 기능의 정상동작에 관한 영향력

TDD(Test-DrivenDevelopment) 란 ?

5

01

TDD 개발 절차

• 테스트 스크립트 개발 -> 개발 -> 리팩토링

TDD 전문서적의 내용을 바탕으로 TDD 를 간단히 설명한다면 ,- TDD 는 코드를 먼저 만드는 것이 아니라 , 테스트 스크립트를 먼저 만든다 .- 그 다음에 실제 서버에서 수행되는 코드를 작성하는데 , 먼저 만든 테스트 스크립트를 수행하면 통과 될 수 있도록 코딩한다 .- 코드 작성을 마치고 , 그 코드의 가독성 , 유지 보수성 등을 높이기 위해서 리팩토링을 한다

애자일 개발론의 Robert C . martin 은 다음의 TDD 원칙을 제시한다- 실패하는 테스트를 작성하기 전에는 절대로 제품코드를 작성하지 않는다 .- 실패하는 테스트 코드를 한 번에 하나이상 작성하지 않는다 .- 현재 실패하고 있는 테스트를 통과하기에 충분한 정도를 넘어서는 제품코드를 작성하지 않는다

6

01

• 만일 수행될 코드를 만든 후 테스트 스크립트를 만들어 테스트하고 , 리팩토링 작업을 했다면 TDD 를 적용한 것이 아닐까 ?

이는 그리 중요치 않다 . 개발을 하는 과정에 있어서 테스트 스크립트를 만들었고 리팩토링을 수행했다면 TDD 를 적용했다고 말할 수 있다 . TDD 의 목적은 소프트웨어의 품질 향상을 시키는 한 방법이라는 것을 잊지 말자 .

• 그럼 도대체 왜 TDD 를 해야 하는가 ? 보통 개발하는데 코드를 짜는 시간 보다 디버깅을 하는 시간이 더 많이 소요 된다 . 그렇다면 디버깅은 보통 어떻게 할까 ? 대부분 개발자들은 자바의 경우 System.out.print() 를 호출 하 거나 Log.debug() 를 호출하는 방법으로 디버깅을 한다 . 물론 이 방법은 개발할 당시에는 문제가 되지 않겠지만 , 이러한 코드가 그대로 운영서버로 올라가게 된다면 한번도 호출되지 않는 이러한 코드들이 메모리를 점유할 것이고 또한 사용자에게 보여지지 않 는 부분이 호출됨에 따라서 (System.out.print() 는 웹 브라우저가 아닌 콘솔에 뿌려지므로 ), 성능에도 영향을 준다 . 그렇다면 JUnit 메소드를 호출해서 테스트를 수행할 경우는 어떨까 ? 어떠한 메소드를 디버깅 한다고 했을 때 , 보통은 WAS 를 띄우고 화면을 클릭해서 해당 메소드를 호출하게 할 것이다 . 이렇게 소요되는 시간과 JUnit 으로 메소드 호출을 통해 테스트를 한다고 했을 때 , 어떤 방법이 더 오래걸릴까 ? 또한 기존 디버깅방법은 재사용성도 못하게 된다 .

7

01

• 어차피 테스터가 테스트를 하는데 , 왜 내가 테스트 코드를 만들어야 하는가 ?

프로그램을 개발할 때 테스터보다 더 그 프로그램의 구동방식에 대해서 잘 알고 있는 사람은 그 프로그램을 지시한 고객과 개발자 이다 . 다시 말하면 제 3 자의 의한 테스트를 수행할 경우 개발자가 직접 수행하는 경우를 비교하면 커버리지 차이가 굉장히 많다는 것이다 . 또한 , 결함을 발견하는 시기에 있어서는 빠르면 빠를 수록 좋다 . 결함을 발견하는 시기가 늦어질 수록 그 결함을 처리하는데 드는 비용이 증가하기 때문이다 .

• TDD 같은 것은 외국 실정에 적합하다 . 시간이 부족한 한국에서는 안 맞는다 ?

회귀테스트에 대해서 다시 한번 생각해보자 . 개발하는데 있어서 시간이 부족하다는 말도 맞는 말이다 . 하지만 메소드 하나를 수정했을 때 관련된 메소드를 점검하고 다음 단계로 넘어가는가 ? 테스트 코드의 개수에 따라 달라질 수 있지만 만들어 놓은 테스트코드를 수행하는데 1 분 정도 걸리는 대상 메소드가 있을 경우 일일이 메뉴얼로 테스트하는데 얼마나 걸릴지 생각해보기 바란다 .

8

01

리팩토링

• 리팩토링의 수행절차 1 . 리팩토링 할 대상을 선정한다 . 2 . 선정된 대상의 테스트 코드를 작성한다 . 3 . 코드를 분해한 후 재조립한다 . 4 . 재조립한 코드를 테스트한다 . 5 . 3 번 작업과 4 번 작업을 반복한다 .

9

01리팩토링해야 할 대상• 반복되는 코드 : 지겨운 Copy & Paste 작업만 수행한 코드가 있다 . 이 경우의 단점은 잘못된 부분이

있어서하나를 수정해야 할 때 다른 모든 코드도 수정해야 한다는 것이다 .

• 긴 메소드 : 하나의 메소드에서 모든 처리를 하면 작성한 본인은 이해할 수 있다 쳐도 , 해당 프로그램을 인수인계 받은 사람은이해하기도 , 수정하기도 어렵다 .

• 큰 클래스 : 하나의 클래스에 너무 많은 메소드나 변수가 있으면 누구도 손대기 두려워 한다 .• 긴 매개변수 목록 : 매개변수가 너무 많으면 나중에 몇 번째 매개변수가 어떤 의미인지 혼동한다 .• 확산을 위한 변경 : 한 클래스의 목적이 여러 부분에서 사용되고 , 각각의 목적에 따라서 수정이

이루어져야 하는 경우 분리하는 것이 좋다 .• 샷건 (산탄총 ) 수술 : 확산을 위한 변경과 같아 보이지만 , 다른 것이 샷건 수술이다 .

하나의 수정을 위해서 여러 클래스를 건드려야 할 경우가 발생된다면 , 차후 하나의 클래스만 수정하는 것이 가능하도록 만드는 것을 의미한다 .

• 기능에 대한 욕심 : 어떤 메소드가 같은 클래스의 메소드보다 , 다른 클래스의 메소드를 더 많이 사용한다면 그 메소드는 많이 사용하는 클래스로옮기는 것이 차라리 낫다 .

• 큰 데이터 덩어리 : 하나의 TO(Transtfer Object or Value Object) 를 여러 곳에서 사용하려고 덕지덕지 변수들을 추가해서 사용하는 경우가상당히 많다 . 비단 TO 가 아니라 일반 클래스에서도 마찬가지다 . 필요 없는 객체가 생성되지 않도록 꼭 필요한 것만 묶어서 재구성 한다 .

• 기본 자료형에 대한 집착 : 너무 기본 자료형만 밝히지 말고 , 필요한 TO 를 만들어서 사용하는 것이 좋다

• Switch 문장 : Switch 문장을 다형성에 맞추어 중복이 최대한 발생하지 않도록 해야 한다 .• 게으른 클래스 : 별로 사용되지 않는 클래스는 없애야 한다 .• 추측한 것들 제거 : 필요한 것이라고 생각해서 만든 것들 중 사용되지 않는 것은 삭제해야 한다 .• 임시 필드 : 임시로 만든 필드가 너무 많고 , 별로 사용되지 않으면 이해하기 어려워지기 때문에

수정해야 한다 .• 메세지 연결 : 메세지를 의미 없이 연속적으로 호출하고 , 호출하고 또 호출하게 되면 간략하게 변경해야

한다 .• 중간자적 입장 : 클래스에 있는 메소드가 주로 다른 클래스를 참조한다면 , 지나친 캡슐화가 된 것이므로

수정한다 .• 높은 연관성 제거 : 두 클래스의 연광성이 너무 높으면 유지 보수할 때 위험하다 .• 다른 인터페이스를 구현한 비슷한 클래스 : 같은 작업을 하지만 , 다른 인터페이스를 구현한 경우를

말한다 . 즉 하는 일은 같은대무엇을 사용해야 하는지 혼동되는 클래스가 있다면 수정해야 한다 .

• 약간 부족한 라이브러리 : 제공받은 라이브러리가 부족한 부분이 있다면 , 기능을 보완하는 클래스를 추가하는 것이 좋다 .

• 잘못된 상속 : 상속받은 클래스가 너무 많은 일을 하거나 복잡할 경우 부모 클래스에게동생을 하나 만들어 달라고 하는 것이 낫다 .

• 불필요한 주석 제거 : 디버깅을 위해서 만든 필요없는 주석들은 제거해야 한다 . 소스의 가독성이 떨어진다 .

이 문서는 나눔글꼴로 작성되었습니다 . 설치하기

마치며…

이번 프로젝트를 들어가면서 TDD 란 걸 처음 알게 되면서이런저런 방법론들에 대해 알아보게 되었습니다 .한번에 TDD 에 대한 PPT 를 다 끝내고 싶었지만 , 여기까지공부하면서도 생각보다 이해가 잘 안되어서 앞으로 파트를 나눠학습회시간에 이어 가 볼 생각 입니다 .

1 부는 TDD 에 대한 개요라고 보시면 될 것 같습니다 .앞으로 개발법이라든지 장점이나 한계점에 대해 연재 하도록하겠습니다 .