1 / 10

Test-Driven Development

Test-Driven Development. STG / 황성 원. TDD(Test-Driven Development) 란 ? TDD 개발법 TDD 의 장점 TDD 의 한계. TDD. TDD 란 ?. TDD. TDD(Test-Driven Development) 란 ?. 01. TDD 목적 또한 개발 된 소프트웨어의 품질을 보장하고 향상시키는 데 있다. TDD 의 목표는 작동하는 깔끔한 코드 “Clean code that works” 이다 . 이를 위해 두 가지 원칙을 제시한다 .

rhonda
Download Presentation

Test-Driven Development

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Test-Driven Development STG/ 황성원

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

  3. TDD란? • TDD

  4. TDD(Test-DrivenDevelopment)란? 01 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에 대한 PPT 를 다 끝내고 싶었지만, 여기까지 공부하면서도 생각보다 이해가 잘 안되어서 앞으로 파트를 나눠 학습회시간에 이어 가 볼 생각 입니다. 1부는 TDD에 대한 개요라고 보시면 될 것 같습니다. 앞으로 개발법이라든지 장점이나 한계점에 대해 연재 하도록 하겠습니다. 이 문서는 나눔글꼴로 작성되었습니다. 설치하기

More Related