Transcript Test-Driven Development

Test-Driven
Development
1. TDD(Test-Driven Development) 란?
2. TDD 개발법
3. TDD 의 장점
4. TDD 의 한계
TDD란?
01
TDD(Test-Driven
Development)란?
TDD 목적 또한 개발 된 소프트웨어의 품질을 보장하고 향상시키는 데 있다.
• 요구사항 분석 -> 설계 -> 개발 -> 테스트 ->배포
4
01
• 테스트 스크립트 개발 -> 개발 -> 리팩토링
5
01
• 만일 수행될 코드를 만든 후 테스트 스크립트를 만들어 테스트하고, 리팩토링 작업을 했다면 TDD를
적용한 것이 아닐까 ?
이는 그리 중요치 않다. 개발을 하는 과정에 있어서 테스트 스크립트를 만들었고 리팩토링을
수행했다면 TDD를 적용했다고 말할 수 있다.
TDD의 목적은 소프트웨어의 품질 향상을 시키는 한 방법이라는 것을 잊지 말자.
• 그럼 도대체 왜 TDD를 해야 하는가?
보통 개발하는데 코드를 짜는 시간 보다 디버깅을 하는 시간이 더 많이 소요 된다.
그렇다면 디버깅은 보통 어떻게 할까? 대부분 개발자들은 자바의 경우 System.out.print()를
호출 하 거나 Log.debug()를 호출하는 방법으로 디버깅을 한다.
물론 이 방법은 개발할 당시에는 문제가 되지 않겠지만, 이러한 코드가 그대로 운영서버로 올라가게
된다면 한번도 호출되지 않는 이러한 코드들이 메모리를 점유할 것이고 또한 사용자에게 보여지지 않
는 부분이 호출됨에 따라서(System.out.print()는 웹 브라우저가 아닌 콘솔에 뿌려지므로), 성능에도
영향을 준다.
그렇다면 JUnit 메소드를 호출해서 테스트를 수행할 경우는 어떨까?
어떠한 메소드를 디버깅 한다고 했을 때, 보통은 WAS를 띄우고 화면을 클릭해서 해당 메소드를
호출하게 할 것이다.
이렇게 소요되는 시간과 JUnit으로 메소드 호출을 통해 테스트를 한다고 했을 때,
어떤 방법이 더 오래걸릴까?
또한 기존 디버깅방법은 재사용성도 못하게 된다.
6
01
• 어차피 테스터가 테스트를 하는데, 왜 내가 테스트 코드를 만들어야 하는가?
프로그램을 개발할 때 테스터보다 더 그 프로그램의 구동방식에 대해서
잘 알고 있는 사람은 그 프로그램을 지시한 고객과 개발자 이다.
다시 말하면 제 3자의 의한 테스트를 수행할 경우 개발자가 직접 수행하는 경우를
비교하면 커버리지 차이가 굉장히 많다는 것이다. 또한, 결함을 발견하는 시기에
있어서는 빠르면 빠를 수록 좋다.
결함을 발견하는 시기가 늦어질 수록 그 결함을 처리하는데 드는 비용이 증가하기 때문이다.
• TDD 같은 것은 외국 실정에 적합하다. 시간이 부족한 한국에서는 안 맞는다?
회귀테스트에 대해서 다시 한번 생각해보자.
개발하는데 있어서 시간이 부족하다는 말도 맞는 말이다. 하지만 메소드 하나를
수정했을 때 관련된 메소드를 점검하고 다음 단계로 넘어가는가 ?
테스트 코드의 개수에 따라 달라질 수 있지만 만들어 놓은 테스트코드를 수행하는데
1분 정도 걸리는 대상 메소드가 있을 경우 일일이 메뉴얼로 테스트하는데
얼마나 걸릴지 생각해보기 바란다.
7
01
• 리팩토링의 수행절차
1 . 리팩토링 할 대상을 선정한다.
2 . 선정된 대상의 테스트 코드를 작성한다.
3 . 코드를 분해한 후 재조립한다.
4 . 재조립한 코드를 테스트한다.
5 . 3번 작업과 4번 작업을 반복한다.
8
리팩토링해야 할 대상
01
• 반복되는 코드 : 지겨운 Copy & Paste 작업만 수행한 코드가 있다. 이 경우의 단점은 잘못된 부분이 있어서
하나를 수정해야 할 때 다른 모든 코드도 수정해야 한다는 것이다.
• 긴 메소드 : 하나의 메소드에서 모든 처리를 하면 작성한 본인은 이해할 수 있다 쳐도, 해당 프로그램을 인수인
계 받은 사람은
이해하기도 , 수정하기도 어렵다.
• 큰 클래스 : 하나의 클래스에 너무 많은 메소드나 변수가 있으면 누구도 손대기 두려워 한다.
• 긴 매개변수 목록 : 매개변수가 너무 많으면 나중에 몇 번째 매개변수가 어떤 의미인지 혼동한다.
• 확산을 위한 변경 : 한 클래스의 목적이 여러 부분에서 사용되고, 각각의 목적에 따라서 수정이 이루어져야 하
는 경우 분리하는 것이 좋다.
• 샷건(산탄총) 수술 : 확산을 위한 변경과 같아 보이지만, 다른 것이 샷건 수술이다.
하나의 수정을 위해서 여러 클래스를 건드려야 할 경우가 발생된다면, 차후 하나의 클래스만 수정하는 것이 가
능하도록 만드는 것을 의미한다.
• 기능에 대한 욕심 : 어떤 메소드가 같은 클래스의 메소드보다, 다른 클래스의 메소드를 더 많이 사용한다면 그
메소드는 많이 사용하는 클래스로
옮기는 것이 차라리 낫다.
• 큰 데이터 덩어리 : 하나의 TO(Transtfer Object or Value Object)를 여러 곳에서 사용하려고 덕지덕지 변수
들을 추가해서 사용하는 경우가
상당히 많다. 비단 TO가 아니라 일반 클래스에서도 마찬가지다. 필요 없는 객체가 생성되지 않도록 꼭 필요한
것만 묶어서 재구성 한다.
• 기본 자료형에 대한 집착 : 너무 기본 자료형만 밝히지 말고, 필요한 TO를 만들어서 사용하는 것이 좋다
• Switch 문장 : Switch 문장을 다형성에 맞추어 중복이 최대한 발생하지 않도록 해야 한다.
• 게으른 클래스 : 별로 사용되지 않는 클래스는 없애야 한다.
• 추측한 것들 제거 : 필요한 것이라고 생각해서 만든 것들 중 사용되지 않는 것은 삭제해야 한다.
• 임시 필드 : 임시로 만든 필드가 너무 많고, 별로 사용되지 않으면 이해하기 어려워지기 때문에 수정해야 한다.
• 메세지 연결 : 메세지를 의미 없이 연속적으로 호출하고, 호출하고 또 호출하게 되면 간략하게 변경해야 한다.
• 중간자적 입장 : 클래스에 있는 메소드가 주로 다른 클래스를 참조한다면, 지나친 캡슐화가 된 것이므로 수정한
다.
• 높은 연관성 제거 : 두 클래스의 연광성이 너무 높으면 유지 보수할 때 위험하다.
• 다른 인터페이스를 구현한 비슷한 클래스 : 같은 작업을 하지만, 다른 인터페이스를 구현한 경우를 말한다. 즉
하는 일은 같은대
무엇을 사용해야 하는지 혼동되는 클래스가 있다면 수정해야 한다.
• 약간 부족한 라이브러리 : 제공받은 라이브러리가 부족한 부분이 있다면, 기능을 보완하는 클래스를 추가하는
것이 좋다.
• 잘못된 상속 : 상속받은 클래스가 너무 많은 일을 하거나 복잡할 경우 부모 클래스에게
동생을 하나 만들어 달라고 하는 것이 낫다.
• 불필요한 주석 제거 : 디버깅을 위해서 만든 필요없는 주석들은 제거해야 한다. 소스의 가독성이 떨어진다.
9
마치며…
이번 프로젝트를 들어가면서 TDD란 걸 처음 알게 되면서
이런저런 방법론들에 대해 알아보게 되었습니다.
한번에 TDD에 대한 PPT 를 다 끝내고 싶었지만, 여기까지
공부하면서도 생각보다 이해가 잘 안되어서 앞으로 파트를 나눠
학습회시간에 이어 가 볼 생각 입니다.
1부는 TDD에 대한 개요라고 보시면 될 것 같습니다.
앞으로 개발법이라든지 장점이나 한계점에 대해 연재 하도록
하겠습니다.
. 설치하기