최근에 영어 공부를 위해 InfoQ에 올라오는 다수의 강의를 듣고 있다. 최근에는 2008 Agile Conference에서 했던 동영상 강의가 올라오고 있다. 도저히 무슨 말인지 모르지만 열심히 듣고 있다. 언제인가 들리겠지 하는 마음으로..
이전에 들었던 동영상 강의 중에 공감하는 동영상 강의가 있어 공유하고자 한다. 주제는 Designing for Testability이다. 테스트 가능하도록 설계하는 방법..
이 동영상 강의는 TestNG 테스트 프레임워크가 가지는 장점에 대하여 설명하면서 강의를 시작한다. 이 동영상 강의에서 이야기하고자 하는 핵심적인 내용은 두번째 강의에서 부터이다. 테스트 용이한 소스 코드를 만들기 위한 이 동영상 강의 핵심적인 내용은 다음과 같다.
첫번째 원칙은 Google guice, Spring 프레임워크와 같은 Dependency Injection(DI) 프레임워크를 사용하는 것이 테스트 가능한 코드를 만들기 위한 좋은 습관이다. Google guice는 상당히 가벼운 DI 프레임워크이고 Spring은 무거운 프레임워크로 소개하고 있으며, Google guice를 강력 추천하고 있다. 프로젝트의 성격에 따라 다르겠지만 DI만 활용할 생각이라면 Google guice를 선택하는 것도 좋다라고 생각한다.
두번째는 이야기하는 내용은 테스트 용이한 코드를 만들기 위해서는 OOP의 원칙을 깰 수도 있다고 이야기하고 있다. 지금까지 private과 final을 적절하게 사용해 캡슐화를 잘 하는 것이 OOP의 원칙이다. 그러나 테스트 용이한 코드를 만들기 위해서는 이 원칙을 깰 수도 있다는 것이다. 나 또한 단순히 테스트를 위하여 많은 메써드를 private에서 default로 변경하였다. 너무 원칙을 고집하기보다는 테스트가 더 중요한 소스 코드라면 충분히 깰만한 가치가 있다고 생각한다. 오히려 private 메써드를 default로 변경했을 때 중복코드 또한 제거할 수 있었으며, 효율적으로 단위테스트를 할 수 있었다. 이와 같은 시도는 지속적으로 리팩토링을 하도록 유도하기까지 한다고 생각한다.
세번째는 TDD에 대한 환상을 깨고 있다. 최근에는 TDD를 하지 않으면 뛰어난 개발자가 아니다라고 생각하는 경향이 있다고 꼬집으면서 TDD가 좋은 것으로 생각하는 부분들에 대하여 이야기하고 있다. 초보 개발자이거나 새로운 개념을 익힐 때는 TDD가 좋은 선택으로 생각되나 모든 상황에서 TDD를 할 필요는 없다고 생각한다. 최근에는 너무 TDD에 집착하는 것은 아닌지 반문해 보고 싶다. 물론 TDD를 통하여 많은 것을 배우고 느끼는 부분이 많지만 반드시 TDD일 필요는 없다고 생각한다. 반드시 테스트 코드를 먼저 만드는 것에 집착하기보다는 적절한 단위 테스트 코드를 만들어나가는 능력을 기르는 것이 더 중요할 것으로 생각한다.
지금 내가 진행하고 있는 프로젝트에서는 반드시 TDD를 고집하지는 않는다. 하지만 단위 테스트의 중요성을 인식하고 있는 개발자들이 자연스럽게 테스트 코드를 만들며 소스 코드를 리팩토링하고 있다. 테스트 Coverage가 소스 코드의 품질을 100% 보장하지는 못하지만 아직까지 80% 이상의 테스트 Coverage를 유지하고 있다. 단위 테스트의 중요성을 인식하고 그 가치를 이해한다면 테스트 코드를 먼저 만드느냐 뒤에 만드느냐에 집착할 필요는 없을 것으로 생각한다.
이전에 들었던 동영상 강의 중에 공감하는 동영상 강의가 있어 공유하고자 한다. 주제는 Designing for Testability이다. 테스트 가능하도록 설계하는 방법..
이 동영상 강의는 TestNG 테스트 프레임워크가 가지는 장점에 대하여 설명하면서 강의를 시작한다. 이 동영상 강의에서 이야기하고자 하는 핵심적인 내용은 두번째 강의에서 부터이다. 테스트 용이한 소스 코드를 만들기 위한 이 동영상 강의 핵심적인 내용은 다음과 같다.
첫번째 원칙은 Google guice, Spring 프레임워크와 같은 Dependency Injection(DI) 프레임워크를 사용하는 것이 테스트 가능한 코드를 만들기 위한 좋은 습관이다. Google guice는 상당히 가벼운 DI 프레임워크이고 Spring은 무거운 프레임워크로 소개하고 있으며, Google guice를 강력 추천하고 있다. 프로젝트의 성격에 따라 다르겠지만 DI만 활용할 생각이라면 Google guice를 선택하는 것도 좋다라고 생각한다.
두번째는 이야기하는 내용은 테스트 용이한 코드를 만들기 위해서는 OOP의 원칙을 깰 수도 있다고 이야기하고 있다. 지금까지 private과 final을 적절하게 사용해 캡슐화를 잘 하는 것이 OOP의 원칙이다. 그러나 테스트 용이한 코드를 만들기 위해서는 이 원칙을 깰 수도 있다는 것이다. 나 또한 단순히 테스트를 위하여 많은 메써드를 private에서 default로 변경하였다. 너무 원칙을 고집하기보다는 테스트가 더 중요한 소스 코드라면 충분히 깰만한 가치가 있다고 생각한다. 오히려 private 메써드를 default로 변경했을 때 중복코드 또한 제거할 수 있었으며, 효율적으로 단위테스트를 할 수 있었다. 이와 같은 시도는 지속적으로 리팩토링을 하도록 유도하기까지 한다고 생각한다.
세번째는 TDD에 대한 환상을 깨고 있다. 최근에는 TDD를 하지 않으면 뛰어난 개발자가 아니다라고 생각하는 경향이 있다고 꼬집으면서 TDD가 좋은 것으로 생각하는 부분들에 대하여 이야기하고 있다. 초보 개발자이거나 새로운 개념을 익힐 때는 TDD가 좋은 선택으로 생각되나 모든 상황에서 TDD를 할 필요는 없다고 생각한다. 최근에는 너무 TDD에 집착하는 것은 아닌지 반문해 보고 싶다. 물론 TDD를 통하여 많은 것을 배우고 느끼는 부분이 많지만 반드시 TDD일 필요는 없다고 생각한다. 반드시 테스트 코드를 먼저 만드는 것에 집착하기보다는 적절한 단위 테스트 코드를 만들어나가는 능력을 기르는 것이 더 중요할 것으로 생각한다.
지금 내가 진행하고 있는 프로젝트에서는 반드시 TDD를 고집하지는 않는다. 하지만 단위 테스트의 중요성을 인식하고 있는 개발자들이 자연스럽게 테스트 코드를 만들며 소스 코드를 리팩토링하고 있다. 테스트 Coverage가 소스 코드의 품질을 100% 보장하지는 못하지만 아직까지 80% 이상의 테스트 Coverage를 유지하고 있다. 단위 테스트의 중요성을 인식하고 그 가치를 이해한다면 테스트 코드를 먼저 만드느냐 뒤에 만드느냐에 집착할 필요는 없을 것으로 생각한다.
이올린에 북마크하기
