일반적인 기업의 소프트웨어(애플리케이션) 엔지니어는 비즈니스의 도메인 지식을 컴퓨터가 이해할 수 있는 형태로 옮기는 작업을 수행합니다. 그리고 우린 이를 코딩이라고 지칭합니다.
비즈니스는 항상 변합니다. 문제를 보다 더 잘 해결하기 위해 지속적으로 성장하는 것이죠. 이러한 과정에서 소프트웨어 엔지니어가 전달하는 도메인 지식은 보다 더 많아지거나 변경됩니다.
이를 위해 소프트웨어 엔지니어는 항상 비지니스 변화에 대한 대응 능력을 갖춘 산출물을 남겨야합니다.
그리고 이러한 비즈니스와 그것을 이루는 기술적 부분의 변화에 대한 대응 능력을 갖춘 Test suite을 보유해야합니다. 이것은 소프트웨어 엔지니어에게 꽤 중요합니다.
리팩토링 내성
테스트에서 리팩토링 내성이란, 제품 코드의 리팩토링에 대해 Test suite이 얼마나 견뎌낼 수 있냐를 이야기합니다.
제품 코드의 변화에 Test suite이 민감하게 반응하여 Test case들이 쉽게 깨지거나 제품 코드의 변화에 대응하기 위해 많은 부분을 다시 작업해야 한다면Test suit이 리팩토링에 대한 내성을 갖추지 못한 것입니다.
반면 제품 코드의 변화에 Test suite이 둔감하게 반응하여 Test case들이 쉽게 깨지지 않거나 대응을 위해 약간의 부분만을 변경하여 유지가 가능하다면 이는 리팩토링에 대한 내성을 갖춘 것입니다.
테스트 커버리지는 85% 내외가 적당
리팩토링 내성을 갖추게 하는 Test suite의 요소는 여러가지가 있을 것 같습니다. 그리고 여기에는 테스트 커버리지가 포함된다고 생각합니다.
테스트 커버리지는 제품 코드의 코드 라인을 Test suite이 얼마나 실행했냐를 수치로 표시합니다. 매우 기계답습니다.
테스트 커버리지 100%는 Test suite이 제품 코드에 매우 강하게 결합되게 합니다. Test suite와 제품 코드의 강한 결합은 리팩토링 내성을 방해합니다. 아주 사소한 조금의 변경이라도 Test suite이 크게 영향 받기 때문이죠. 때로는 이것이 제품 코드의 지속 성장을 방해하기도 합니다.
테스트 커버리지 100%는 키보드와 테블릿을 자석(약한 결합)이 아닌 강력 접착제(강한 결합)로 붙인 것과 같습니다.
테스트 커버리지를 85% 정도로 유지하는 것이 좋습니다. 조금 약하게 결합하여 제품 코드의 변화와 리팩토링을 자유롭게하고, Test suite가 해당 변화를 발빠르게 따라가도록 하는것이죠.
가치 없는 테스트 제거로 테스트 커버리지 낮추기
테스트 커버리지 100%를 갖출 수 있었던건 ‘가치 없는 테스트’를 포함시켰기 때문일 가능성이 높습니다.
소프트웨어 엔지니어는 ‘가치 있는 테스트’와 ‘가치 없는 테스트’를 구별해야합니다. 그리고 ‘가치 없는 테스트’를 제거하여 리팩토링 내성을 확보합시다.
도메인 지식을 표현한 제품 코드의 테스트 케이스는 항상 가치가 있습니다. 그러나 단순 로깅에 대한 테스트 케이스는 가치가 없을 수 있습니다.
마치며
Test suite의 리팩토링 내성은 지속 가능한 소스 코드를 남기는데 유용하게 작용합니다.
