Test-Driven Development

Presentation on theme: "Test-Driven Development"— Presentation transcript:

1 Test-Driven Development
STG / 황성원

2 TDD(Test-Driven Development) 란? TDD 개발법 TDD 의 장점 TDD 의 한계

3 TDD란? TDD

4 TDD(Test-Driven Development)란?
01 TDD(Test-Driven Development)란? TDD 목적 또한 개발 된 소프트웨어의 품질을 보장하고 향상시키는 데 있다. TDD의 목표는 작동하는 깔끔한 코드 “Clean code that works”이다 . 이를 위해 두 가지 원칙을 제시한다. 오직 자동화된 테스트가 실패할 경우에만 새로운 코드를 작성한다 중복을 제거한다. 일반적인 개발 절차는 다음과 같이 진행 되어 왔다. 요구사항 분석 -> 설계 -> 개발 -> 테스트 ->배포 기존 개발법엔 소프트웨어 개발을 느리게 하는 잠재적 위험들이 존재한다 - 소비자의 요구사항의 불 명확성 - 완벽한 설계에 대한 부담 - 실제 코드와 설계간의 갈등 - 수정이 다른 기능의 정상동작에 관한 영향력

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 리팩토링해야 할 대상 반복되는 코드 : 지겨운 Copy & Paste 작업만 수행한 코드가 있다. 이 경우의 단점은 잘못된 부분이 있어서 하나를 수정해야 할 때 다른 모든 코드도 수정해야 한다는 것이다. 긴 메소드 : 하나의 메소드에서 모든 처리를 하면 작성한 본인은 이해할 수 있다 쳐도, 해당 프로그램을 인수인계 받은 사람은 이해하기도 , 수정하기도 어렵다. 큰 클래스 : 하나의 클래스에 너무 많은 메소드나 변수가 있으면 누구도 손대기 두려워 한다. 긴 매개변수 목록 : 매개변수가 너무 많으면 나중에 몇 번째 매개변수가 어떤 의미인지 혼동한다. 확산을 위한 변경 : 한 클래스의 목적이 여러 부분에서 사용되고, 각각의 목적에 따라서 수정이 이루어져야 하는 경우 분리하는 것이 좋다. 샷건(산탄총) 수술 : 확산을 위한 변경과 같아 보이지만, 다른 것이 샷건 수술이다. 하나의 수정을 위해서 여러 클래스를 건드려야 할 경우가 발생된다면, 차후 하나의 클래스만 수정하는 것이 가능하도록 만드는 것을 의미한다. 기능에 대한 욕심 : 어떤 메소드가 같은 클래스의 메소드보다, 다른 클래스의 메소드를 더 많이 사용한다면 그 메소드는 많이 사용하는 클래스로 옮기는 것이 차라리 낫다. 큰 데이터 덩어리 : 하나의 TO(Transtfer Object or Value Object)를 여러 곳에서 사용하려고 덕지덕지 변수들을 추가해서 사용하는 경우가 상당히 많다. 비단 TO가 아니라 일반 클래스에서도 마찬가지다. 필요 없는 객체가 생성되지 않도록 꼭 필요한 것만 묶어서 재구성 한다. 기본 자료형에 대한 집착 : 너무 기본 자료형만 밝히지 말고, 필요한 TO를 만들어서 사용하는 것이 좋다 Switch 문장 : Switch 문장을 다형성에 맞추어 중복이 최대한 발생하지 않도록 해야 한다. 게으른 클래스 : 별로 사용되지 않는 클래스는 없애야 한다. 추측한 것들 제거 : 필요한 것이라고 생각해서 만든 것들 중 사용되지 않는 것은 삭제해야 한다. 임시 필드 : 임시로 만든 필드가 너무 많고, 별로 사용되지 않으면 이해하기 어려워지기 때문에 수정해야 한다. 메세지 연결 : 메세지를 의미 없이 연속적으로 호출하고, 호출하고 또 호출하게 되면 간략하게 변경해야 한다. 중간자적 입장 : 클래스에 있는 메소드가 주로 다른 클래스를 참조한다면, 지나친 캡슐화가 된 것이므로 수정한다. 높은 연관성 제거 : 두 클래스의 연광성이 너무 높으면 유지 보수할 때 위험하다. 다른 인터페이스를 구현한 비슷한 클래스 : 같은 작업을 하지만, 다른 인터페이스를 구현한 경우를 말한다. 즉 하는 일은 같은대 무엇을 사용해야 하는지 혼동되는 클래스가 있다면 수정해야 한다. 약간 부족한 라이브러리 : 제공받은 라이브러리가 부족한 부분이 있다면, 기능을 보완하는 클래스를 추가하는 것이 좋다. 잘못된 상속 : 상속받은 클래스가 너무 많은 일을 하거나 복잡할 경우 부모 클래스에게 동생을 하나 만들어 달라고 하는 것이 낫다. 불필요한 주석 제거 : 디버깅을 위해서 만든 필요없는 주석들은 제거해야 한다. 소스의 가독성이 떨어진다. 01

10 이번 프로젝트를 들어가면서 TDD란 걸 처음 알게 되면서 이런저런 방법론들에 대해 알아보게 되었습니다.
마치며… 이번 프로젝트를 들어가면서 TDD란 걸 처음 알게 되면서 이런저런 방법론들에 대해 알아보게 되었습니다. 한번에 TDD에 대한 PPT 를 다 끝내고 싶었지만, 여기까지 공부하면서도 생각보다 이해가 잘 안되어서 앞으로 파트를 나눠 학습회시간에 이어 가 볼 생각 입니다. 1부는 TDD에 대한 개요라고 보시면 될 것 같습니다. 앞으로 개발법이라든지 장점이나 한계점에 대해 연재 하도록 하겠습니다. 이 문서는 나눔글꼴로 작성되었습니다. 설치하기