Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Test driven development

469 views

Published on

TDD 란?

Published in: Education
  • Be the first to comment

  • Be the first to like this

Test driven development

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

×