[지민재] 5장 - 자동 테스트: 좋은 소프트웨어를 만드는 최고의 습관

05장/지민재.md

@@ -0,0 +1,27 @@
+## 5장 핵심 정리
+
+소프트웨어의 품질을 높이기 위해서는 코드를 작성하는 것만큼 테스트를 꾸준히 작성하는 습관이 중요하다. 자동 테스트는 코드가 의도한 대로 동작하는지 확인하는 역할을 하며, 기존 기능이 깨지지 않았는지 검증하고 버그를 개발 초기에 발견할 수 있도록 돕는다. 또한 테스트는 코드가 어떤 동작을 해야 하는지 알려주는 문서가 되기도 하고, 테스트를 작성하는 과정에서 책임이 지나치게 많거나 구조가 복잡한 코드를 발견해 더 나은 설계로 개선할 수도 있다. 결국 **테스트는 단순히 버그를 찾는 수단이 아니라, 코드를 이해하고 변경에 대한 자신감을 얻도록 도와주는 안전장치**다.
+
+자동 테스트는 크게 단위 테스트, 통합 테스트, 종단 간 테스트(E2E)로 나뉜다. 단위 테스트는 개별 함수나 구성요소가 독립적으로 올바르게 동작하는지 확인하고, 통합 테스트는 여러 구성요소가 연결되어 함께 작동하는지 검증한다. 종단 간 테스트는 사용자 인터페이스부터 백엔드까지 애플리케이션 전체의 흐름을 확인한다. 테스트 범위가 넓어질수록 실행 시간이 길어지고 유지보수 비용이 커지기 때문에, **빠르고 독립적인 단위 테스트를 중심으로 구성하고 통합 테스트와 E2E 테스트를 필요한 만큼 보완하는 것**이 중요하다.
+
+테스트를 작성할 때는 모든 코드를 무조건 검증하기보다 실제로 의미 있는 동작에 집중해야 한다. 직접 작성한 핵심 로직과 비즈니스 규칙을 중심으로 정상적인 상황뿐 아니라 경계 조건과 예외 상황도 확인해야 한다. 반면 언어나 프레임워크 자체의 기능, 단순한 getter/setter, 자동 생성된 코드처럼 검증할 필요가 적은 부분은 테스트 대상에서 제외할 수 있다. 단위 테스트에서는 모의 객체(Mock)를 사용해 외부 의존성을 대체하고 테스트 대상을 독립적으로 검증할 수 있으며, 단정문(Assertion)을 통해 실제 결과가 예상한 결과와 일치하는지 확인한다.
+
+테스트를 작성하는 방식에는 구현 전에 테스트부터 작성하는 테스트 선행 방식과 기능을 구현한 뒤 테스트를 작성하는 테스트 후행 방식이 있다. 특히 테스트 주도 개발(TDD)은 실패하는 테스트를 작성하고, 이를 통과하는 최소한의 코드를 구현한 뒤, 동작을 유지하면서 코드를 개선하는 빨간불-녹색불-리팩토링 과정을 반복한다. 어떤 방식을 선택하든 중요한 것은 테스트를 통해 요구사항과 예상 결과를 명확히 하고, 실제 동작을 제대로 검증하는 것이다. 또한 코드 실행률은 테스트 중 코드가 얼마나 실행되었는지를 보여주는 지표일 뿐, 테스트의 품질을 보장하지는 않는다. **실행률이라는 숫자를 높이는 것보다 실제로 버그를 발견하고 기존 기능을 보호할 수 있는 테스트를 작성하는 데 집중해야 한다.**
+
+## 인상 깊었던 부분
+
+> 중요한 것은 꾸준히 건강한 선택을 하는 것이다. 마찬가지로 유지보수하기 좋고 높은 품질의 소프트웨어를 만드는 일도 코드 작성, 리뷰, 테스트 과정에서 좋은 습관을 꾸준히 실천한 결과다. 건강한 생활방식을 유지하는 것과 마찬가지로, 이런 습관은 쉽게 길러지지 않고 변명은 오히려 발목만 잡을 뿐이다.
+
+→ 읽으면서 뜨끔했다... 사실 테스트에 대해 잘 모르는 편이고, 테스트 코드를 직접 작성하는 일도 드물다. 평소에 하는 테스트라고는 요구사항에 맞게 동작하는지 수동으로 하나씩 확인하는 정도다. 그런데 이 과정에도 생각보다 많은 시간과 노력이 들어간다. 꼼꼼하게 확인했다고 생각해도 실수로 놓치는 부분이 있어 이슈가 re-open 경우도 종종 있다... 회사 QA 매니저 분들은 TC를 엑셀에 하나씩 작성해서 검증하시는데, 자동 테스트를 도입하면 이런 반복적인 작업의 부담도 줄일 수 있지 않을까? 자동 테스트를 제대로 이해하고 활용하면 개발 과정에서 얼마나 많은 시간과 비용을 아낄 수 있을지 궁금해졌다.
+
+> 프로젝트에 문서가 제대로 갖춰진 경우는 드물다. 운이 좋으면 선임 개발자나 도메인 전문가와 상의해서 업무를 시작하기 전에 전반적인 개요를 파악할 수도 있다. 하지만 이런 상황이 늘 가능한 것은 아니며, 문서가 빈약하거나 아예 없을 수도 있다. 이때 잘 작성된 테스트가 있다면 큰 힘이 된다.
+
+→ 메이커스 면접에서 인수인계 문서나 프로젝트 문서가 제대로 갖춰져 있지 않은 문제가 고질적이라는 이야기를 들었던 기억이 난다. 그렇다면 테스트 코드가 이런 문제를 보완하는 수단이 될 수 있을까? 테스트가 기능의 동작을 설명해 준다면, 기존 코드의 의도나 동작 방식을 파악하는 데 도움이 될 것 같다. 다만 테스트가 프로젝트 전체의 히스토리나 설계 배경까지 설명해 줄 수 있는 것은 아닐 것 같다. 우선 이 부분에서 말하는 테스트의 역할은 특정 기능이 어떤 조건에서 어떻게 동작하는지 알려주고, 문제가 발생했을 때 관련 코드를 따라가며 원인을 파악할 수 있도록 돕는 것에 가까워 보인다. 그렇다면 테스트는 인수인계 문서 자체를 대체하기보다는, 문서만으로 파악하기 어려운 실제 동작을 이해하는 데 도움을 주는 도구라고 볼 수 있을까??
+
+> 테스트를 작성하다 보면 기능을 검증하게 될 뿐만 아니라 더 나은 코드 설계로 이어진다. 잠재적인 결함이 문제로 드러나기 전에 미리 발견하게 해주며, 유지보수하기 좋고 재사용 가능한 소프트웨어를 만들도록 도와준다.
+
+→ 작년 우테코 프리코스를 진행하면서 테스트 코드를 작성했던 경험이 떠올랐다. 당시에는 작은 기능 하나를 구현하는 데도 테스트를 계속 작성해야 하는 이유가 잘 와닿지 않았다. 그런데 지금 돌이켜보면 테스트를 작성하면서 빠뜨린 요구사항을 발견해 추가하기도 했고, 하나의 메서드가 지나치게 많은 책임을 지고 있다는 사실을 깨닫고 리팩토링하기도 했다. 테스트를 단순히 구현한 기능이 제대로 동작하는지 확인하는 과정으로만 생각했는데, 오히려 테스트를 작성하는 과정 자체가 코드의 문제점을 발견하고 설계를 개선하는 계기가 되었던 것이다. 당시에는 그 의미를 깊이 이해하지 못했지만... 고민했던 것들을 다시 떠올리면서 개발 공부를 하며 익힌 것들을 꾸준히 실천하고 있는지 돌아보게 됐다.
+
+> 테스트를 해야 하는 이유를 알았으니, 이제 무엇을 테스트해야 하고 무엇을 테스트하지 말아야 할지 살펴보자.
+
+→ 테스트를 작성해야 한다는 이야기는 많이 들어봤지만, 테스트하지 말아야 할 것을 따로 설명한다는 점이 흥미로웠다. 테스트는 많이 작성할수록 좋은 것이라고 막연하게 생각했는데, 실제로는 테스트할 대상과 범위를 적절하게 정하는 것도 중요하다는 것을 알게 됐다. 테스트가 필요하지 않은 코드까지 검증하려고 하면 작성하고 관리하는 데 불필요한 비용이 들 수 있기 때문이다. 그렇다면 어떤 기준으로 테스트할 대상을 정해야 할까? 단순히 코드의 양이나 복잡도를 기준으로 판단하는 것이 아니라, 해당 코드가 중요한 동작을 수행하는지, 문제가 발생했을 때 어떤 영향을 미치는지를 고려해야 할 것 같다.