Refactoring리팩토링

4 장 테스트 만들기

아꿈사 http://cafe.naver.com/architect1TTF http://www.npteam.net

시작■ 리팩토링과 테스트

- 리팩토링 할 때 견고한 테스트는 필수조건이다 .

- 리팩토링을 자동화하는 도구가 있더라도 , 테스트는 여전히 중요하다 .

- 잘 짜여진 테스트는 프로그래밍을 빠르게 한다 .

- 이것은 정말 놀라운 사실이며 , 많은 프로그래머들의 직관과도 반대되는 것이다 .

자체 테스트 코드의 가치■ 대부분의 프로그래머들이 시간을 보내는 방법

- 무엇을 해야 하는지 생각한다 .

- 디자인을 하느라 시간을 보낸다 .

- 대부분의 시간은 디버깅을 하면서 보낸다 .

- 실제로 코드를 작성하는 시간은 매우 적다 .

자체 테스트 코드의 가치■ 자체 테스트 코드의 길로 들어선 계기

- 92 년 OOPSLA 에서 누군가와의 대화를 통해 , “ 클래스는 그 자신의 테스트를 포함하고 있어야 한다 .”

- 테스트를 체계화 하는데 좋은 방법이라고 생각 . “ 클래스는 그 자신을 테스트하는데 사용될 수 있는 메소드를 가지고 있어야 한다 .”

- 당시 점진적 개발에 관심이 많았으며 , 각각의 단계가 끝날 때마다 클래스에 메소드를 추가함 .

자체 테스트 코드의 가치■ 자체 테스트 코드의 길로 들어선 계기

- 테스트 메소드를 실행하는 것은 간단했지만 , 테스트는 여전히 지루한 작업이었다 .

- 화면을 모니터링 하면서 결과를 확인하는 대신 , 컴퓨터가 테스트를 스스로 하도록 할 수 있다는 것을 깨달았다 .

핵심 : 모든 테스트를 완전히 자동화하고 , 테스트가 자신의 결과를 스스로 확인하게 하라 .

자체 테스트 코드의 가치■ 시간을 절약하는 버그 탐지기 설치

- 테스트를 실행하는 것은 컴파일을 하는 것 만큼이나 쉬워졌다 .

- 디버깅에 많은 시간을 허비하지 않게 되고 , 그 시간만큼 생산성이 높아졌다 .

- 버그가 생기더라도 테스트가 짧은 시간에 반복적으로 실행되기 때문에 적은 디버깅 시간을 투자하여 , 버그의 원인을 찾아낼 수 있다 .

핵심 : 한 벌의 테스트는 버그를 찾는데 걸리는 시간을 엄청나게 단축시키는 강력한 버그 탐지기이다 .

자체 테스트 코드의 가치■ 테스트 작성이 쉽다 (?)

- 테스트를 작성하기 위해서는 별도의 코드를 많이 작성하기 때문에 다른 사람들을 설득하기 어렵다 .

- 테스트 코드를 작성하는 것이 프로그래밍을 빠르게 한다는 사실을 경험하지 못했다면 , 수긍하기 어렵다 . ( 결국 경험하지 못하면 알기 어렵다 .)

- 그나마 수작업으로 테스트하는 것보다 , 자동화된 테스트를 위해 테스트를 작성하는 것은 재미있는 작업이 될 수도 있다 .

자체 테스트 코드의 가치■ 테스트를 작성하기 좋은 시점은 ?

- 테스트를 작성하기 좋은 시점은 프로그래밍을 시작하기 전이다 .

- 기능 추가를 위해 테스트를 먼저 작성하면 , 기능 추가를 위해 무엇을 해야 할지 명확히 알 수 있다 .

- 또한 구현보다는 인터페이스에 집중할 수 있다 . ( 이렇게 하는 것은 항상 바람직한 일이다 .)

- 코딩을 완료할 명확한 지점 ( 테스트를 통과하는 지점 ) 을 갖게 된다 .

자체 테스트 코드의 가치■ 테스트는 얼만큼 자주 해야 할까 ?

- 익스트림 프로그래밍 (eXtream Programming) 에서는 테스트를 자주하는 것이 매우 중요하다 .

- 익스트림 프로그래머는 테스트에 대단히 열성적이고 , 빠른 개발을 원하기 때문에 , 테스트를 사용한다 .

- 리팩토링에서는 테스트를 필요로 하고 , 리팩토링을 원한다면 테스트를 작성해야 한다 .

- 테스트를 전혀 안 하는 것보다는 아주 적은 테스트로도 놀랄만큼 큰 이득을 얻을 수 있다 .

Junit 테스트 프레임워크■ 단위 테스트와 기능 테스트의 차이점

- 단위 테스트• 프로그래머 입장에서 생산성을 향상시키기 위한 테스트• 하나의 패키지 내에서 패키지를 검증하는 수단 • 다른 패키지에 대한 인터페이스까지는 테스트하지만 그 이상은 테스트 하지 않는다 .

- 기능 테스트• 소프트웨어 전체가 제대로 작동하는지 확인하기 위해

작성된다 .• 사용자에게 확실한 품질을 제공하지만 ,

프로그래머의 생산성은 상관하지 않는다 .• 기능 테스트는 전체를 하나의 블랙박스로 취급한다 .

Junit 테스트 프레임워크■ 버그를 처리하는 과정

- 버그 발견 - 버그 리포트 작성 - 버그가 표면으로 드러나도록 하는 단위 테스트 추가 - 버그를 찾을 범위를 좁히기 위한 단위 테스트 추가

단위 테스트는 버그를 찾아내는데 도움을 주고 , 비슷한 버그가 다시 나오지 못하도록 한다 .

핵심 : 버그 리포트를 받으면 , 먼저 그 버그를 밖으로 드러나게 할 수 있는 단위 테스트를 작성하라 .

테스트 추가하기■ 결국 테스트는 버그를 잡기 위한 것 - 테스트는 문제가 생길만한 곳에 집중되어야 한다 .

- 너무 많은 테스트를 작성하려다 보면 , 오히려 소홀해질 수 있다 .

- 적은 노력으로 큰 효과를 볼 수 있는 생산적인 테스트를 하자 .

- 뭔가 잘못되었을 때에는 경계조건을 생각하고 , 테스트를 경계조건에 집중한다 .

핵심 : “ 완전한 테스트”를 실행하지 않는 것 보다는 , “불완전한 테스트”를 실행하는 것이 낫다 .

테스트 추가하기■ 코드를 대하는 방식을 바꿔보자 !

- 어떻게 하면 적극적으로 코드를 파괴시킬 수 있는지 생각한다 . ( 이렇게 생각하면 마음 상태가 생산적이고 재미있는 상태가 된다 .)

- 예상되는 에러를 테스트 코드로 작성한다 .

핵심 : 뭔가 잘못되리라 예상될 때 적절한 예외 (Exception) 가 발생하는지 테스트를 하는 것을 잊지 마라 .

테스트 추가하기■ 테스트는 위험이 있는 곳에 집중해야 한다 . - 테스트 코드가 많다고 버그가 발생되는 것도 아니고 , 너무 많은 테스트 코드를 작성하려다가 오히려 아무것도 작성하지 않게 될 위험이 있다 .

- 테스트로 모든 버그를 찾을 수 없겠지만 , 리팩토링을 하면 코드를 더 잘 이해하게 되고 , 더 많은 버그를 찾을 수 있다 . ( 테스트 + 리팩토링 조합으로 버그를 찾을 수 있다 .)

핵심 : 테스트로 모든 버그를 잡을 수 없다는 걱정 때문에 , 대부분의 버그를 잡을 수 있는 “ 테스트를 작성하는 것”을 멈추지 마라 .

테스트 추가하기■ 객체의 상속성과 다형성은 테스트를 어렵게 한다 .

- 테스트할 조합이 많다 . - 모든 조합을 테스트하기보다 , 독립적인 모듈에 대한 테스트를 한다 .

- 모든 버그를 잡기 위해 오랜 시간을 보내는 것보다 ,

대부분의 버그를 잡기 위해 합당한 시간을 보내는 것이 낫다 .

결론 좋은 버그 탐지기를 만들고 자주 실행해라 .

이것은 어느 개발에서나 훌륭한 도구이고 ,

리팩토링을 하기 위한 필수조건이다 .

감사합니다 .