1. Refactoring 리팩토링 4장 테스트만들기 아꿈사http://cafe.naver.com/architect1 TTF http://www.npteam.net

2. 시작 ■ 리팩토링과 테스트 - 리팩토링 할 때 견고한 테스트는 필수조건이다. - 리팩토링을 자동화하는 도구가 있더라도, 테스트는 여전히 중요하다. - 잘 짜여진 테스트는 프로그래밍을 빠르게 한다. - 이것은 정말 놀라운 사실이며, 많은 프로그래머들의 직관과도 반대되는 것이다.

3. 자체 테스트 코드의 가치 ■ 대부분의 프로그래머들이 시간을 보내는 방법 - 무엇을 해야 하는지 생각한다. - 디자인을 하느라 시간을 보낸다. - 대부분의 시간은 디버깅을 하면서 보낸다. - 실제로 코드를 작성하는 시간은 매우 적다.

4. 자체 테스트 코드의 가치 ■ 자체 테스트 코드의 길로 들어선 계기 - 92년 OOPSLA에서 누군가와의 대화를 통해, “클래스는 그 자신의 테스트를 포함하고 있어야 한다.” - 테스트를 체계화 하는데 좋은 방법이라고 생각. “클래스는 그 자신을 테스트하는데 사용될 수 있는 메소드를 가지고 있어야 한다.” - 당시 점진적 개발에 관심이 많았으며, 각각의 단계가 끝날 때마다 클래스에 메소드를 추가함.

5. 자체 테스트 코드의 가치 ■ 자체 테스트 코드의 길로 들어선 계기 - 테스트 메소드를 실행하는 것은 간단했지만, 테스트는 여전히 지루한 작업이었다. - 화면을 모니터링 하면서 결과를 확인하는 대신, 컴퓨터가 테스트를 스스로 하도록 할 수 있다는 것을 깨달았다. 핵심 : 모든 테스트를 완전히 자동화하고, 테스트가 자신의 결과를 스스로 확인하게 하라.

6. 자체 테스트 코드의 가치 ■ 시간을 절약하는 버그 탐지기 설치 - 테스트를 실행하는 것은 컴파일을 하는 것 만큼이나 쉬워졌다. - 디버깅에 많은 시간을 허비하지 않게 되고, 그 시간만큼 생산성이 높아졌다. - 버그가 생기더라도 테스트가 짧은 시간에 반복적으로 실행되기 때문에 적은 디버깅 시간을 투자하여, 버그의 원인을 찾아낼 수 있다. 핵심 : 한 벌의 테스트는 버그를 찾는데 걸리는 시간을 엄청나게 단축시키는 강력한 버그 탐지기이다.

7. 자체 테스트 코드의 가치 ■ 테스트 작성이 쉽다(?) - 테스트를 작성하기 위해서는 별도의 코드를 많이 작성하기 때문에 다른 사람들을 설득하기 어렵다. - 테스트 코드를 작성하는 것이 프로그래밍을 빠르게 한다는 사실을 경험하지 못했다면, 수긍하기 어렵다. (결국 경험하지 못하면 알기 어렵다.) - 그나마 수작업으로 테스트하는 것보다, 자동화된 테스트를 위해 테스트를 작성하는 것은 재미있는 작업이 될 수도 있다.

8. 자체 테스트 코드의 가치 ■ 테스트를 작성하기 좋은 시점은? - 테스트를 작성하기 좋은 시점은 프로그래밍을 시작하기 전이다. - 기능 추가를 위해 테스트를 먼저 작성하면, 기능 추가를 위해 무엇을 해야 할지 명확히 알 수 있다. - 또한 구현보다는 인터페이스에 집중할 수 있다. (이렇게 하는 것은 항상 바람직한 일이다.) - 코딩을 완료할 명확한 지점(테스트를 통과하는 지점)을 갖게 된다.

9. 자체 테스트 코드의 가치 ■ 테스트는 얼만큼 자주 해야 할까? - 익스트림 프로그래밍(eXtream Programming)에서는 테스트를 자주하는 것이 매우 중요하다. - 익스트림 프로그래머는 테스트에 대단히 열성적이고, 빠른 개발을 원하기 때문에, 테스트를 사용한다. - 리팩토링에서는 테스트를 필요로 하고, 리팩토링을 원한다면 테스트를 작성해야 한다. - 테스트를 전혀 안 하는 것보다는 아주 적은 테스트로도 놀랄만큼큰 이득을 얻을 수 있다.

11. 하나의 패키지 내에서 패키지를 검증하는 수단

13. 사용자에게 확실한 품질을 제공하지만,프로그래머의 생산성은 상관하지 않는다.

15. 테스트 추가하기 ■ 결국 테스트는 버그를 잡기 위한 것 - 테스트는 문제가 생길만한 곳에 집중되어야 한다. - 너무 많은 테스트를 작성하려다 보면, 오히려 소홀해질 수 있다. - 적은 노력으로 큰 효과를 볼 수 있는 생산적인 테스트를하자. - 뭔가 잘못되었을 때에는 경계조건을 생각하고, 테스트를 경계조건에 집중한다. 핵심 : “완전한 테스트”를실행하지 않는 것 보다는, “불완전한 테스트”를 실행하는 것이 낫다.

16. 테스트 추가하기 ■ 코드를 대하는 방식을 바꿔보자! - 어떻게 하면 적극적으로 코드를 파괴시킬 수 있는지 생각한다. (이렇게 생각하면 마음 상태가 생산적이고 재미있는 상태가 된다.) - 예상되는 에러를 테스트 코드로 작성한다. 핵심 : 뭔가 잘못되리라 예상될 때 적절한 예외(Exception)가 발생하는지 테스트를 하는 것을 잊지 마라.

17. 테스트 추가하기 ■ 테스트는 위험이 있는 곳에 집중해야 한다. - 테스트 코드가 많다고 버그가 발생되는 것도 아니고, 너무 많은 테스트 코드를 작성하려다가 오히려 아무것도 작성하지 않게 될 위험이 있다. - 테스트로 모든 버그를 찾을 수 없겠지만, 리팩토링을 하면 코드를 더 잘 이해하게 되고, 더 많은 버그를 찾을 수 있다. (테스트 + 리팩토링 조합으로 버그를 찾을 수 있다.) 핵심 : 테스트로 모든 버그를 잡을 수 없다는 걱정 때문에, 대부분의 버그를 잡을 수 있는 “테스트를 작성하는 것”을멈추지 마라.

18. 테스트 추가하기 ■ 객체의 상속성과 다형성은 테스트를 어렵게 한다. - 테스트할 조합이 많다. - 모든 조합을 테스트하기보다, 독립적인 모듈에 대한 테스트를 한다. - 모든 버그를 잡기 위해 오랜 시간을 보내는 것보다, 대부분의 버그를 잡기 위해 합당한 시간을 보내는 것이 낫다.

19. 결론 좋은 버그 탐지기를 만들고 자주 실행해라. 이것은 어느 개발에서나 훌륭한 도구이고, 리팩토링을 하기 위한 필수조건이다.

20. 감사합니다.