From 4e46a1ef4dd5f4bf559ecfb3117a3e2ff6d3f5d5 Mon Sep 17 00:00:00 2001 From: constantly-dev Date: Tue, 13 Oct 2026 02:11:23 +0900 Subject: [PATCH] =?UTF-8?q?05=EC=9E=A5=20=EC=9D=B4=EC=A7=84=ED=98=81=20?= =?UTF-8?q?=EC=A0=95=EB=A6=AC=20=EC=B6=94=EA=B0=80?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-Authored-By: Claude Sonnet 5.5 --- .../\354\235\264\354\247\204\355\230\201.md" | 38 +++++++++++++++++++ 1 file changed, 38 insertions(+) create mode 100644 "05\354\236\245/\354\235\264\354\247\204\355\230\201.md" diff --git "a/05\354\236\245/\354\235\264\354\247\204\355\230\201.md" "b/05\354\236\245/\354\235\264\354\247\204\355\230\201.md" new file mode 100644 index 0000000..7eebbdf --- /dev/null +++ "b/05\354\236\245/\354\235\264\354\247\204\355\230\201.md" @@ -0,0 +1,38 @@ +# 5장. 자동 테스트: 좋은 소프트웨어를 만드는 최고의 습관 + +## 자동 테스트 유형 + +테스트 피라미드가 소프트웨어 테스트의 근본적인 '득실' 관계에 따라 형성됨을 기억해야 한다. +결국 최상단의 e2e 테스트는 많은 범위를 커버하는만큼 유지보수가 굉장히 힘들다는 것을 명확하게 인지해야한다. +작은 UI 수정에도 전체 테스트가 깨질 수 있기 때문이다. + +최근 지원서 제출하는 기능에 테스트를 고민한 경험이 있다. +명확한 마감 기한에 따른 유저의 제출 실패 여부가 조직에 대한 신뢰 문제로 연결될 수 있기 때문에 테스트가 있으면 좋겠다고 판단했다. +그렇다면 어떤 테스트가 적절할까? +최종 제출까지 여러 조건들과 API 호출 성공여부까지 모두 중요한 하나의 큰 과정을 생각하면 e2e 테스트가 필요해보인다. +하지만 책에서 말하듯 득실 관계를 판단해야한다. 아래 질문에 대해 스스로 생각해 보는 시간을 가져본다. + +- 하나의 text field가 추가된다면 테스트가 깨지지 않는가? +- 그렇다면 그 테스트를 다시 기능과 매칭시키기 위해서는 어떻게 해야할까? +- 테스트 추가 과정을 자동화할 수는 있는가? 그 비용은 없는가? + +이렇게 생각하면 결코 e2e만이 정답은 아니라고 판단이 된다. +주변 현업 개발자들의 의견을 들어봐도 해당 e2e테스트의 유지보수를 꽤 큰 비용으로 바라보고 있고, 이 코드와의 일치를 +자동화하는 것에 대해서도 많은 고민이 필요한 것으로 보인다. + +결국 선택의 문제인 것 같다. 조직의 규모, 해결하려는 문제 등을 전부 따져보고 적절한 테스트를 고르는 것이 시작이라고 생각한다. + +## 테스트 작성 연습에 대해 + +가장 좋은 시작은 책에서 언급하듯 오픈소스의 테스트 코드를 많이 읽어보고 파악하는 것이다. +나름의 체계를 갖춘 규모가 있는 오픈소스의 테스트 코드를 보며 작성방법과 선택을 파악할 수 있다. + +오픈소스를 뜯어보는 나만의 규칙은 아래와 같았다. + +1. 공식 문서 quick start 문서로 주 기능 파악 +2. 전체 구조 파악 (아키텍쳐) +3. 기능 코드 흐름 파악 (추상화된 높은 레벨의 함수 등) +4. 그 구현을 내부 동작 파악 (실제 낮은 레벨의 구현 코드) + +이 전체 흐름을 파악하는데 있어 테스트 코드를 먼저 파악해보는 습관을 들여보면 좋을 것 같다. +어떤 기능을 가졌는지, 어떠한 엣지 케이스를 고려하는지 등 파악에 테스트 코드가 큰 도움이 될 것 같다.