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

05장/이진혁.md

@@ -0,0 +1,38 @@
+# 5장. 자동 테스트: 좋은 소프트웨어를 만드는 최고의 습관
+
+## 자동 테스트 유형
+
+테스트 피라미드가 소프트웨어 테스트의 근본적인 '득실' 관계에 따라 형성됨을 기억해야 한다.
+결국 최상단의 e2e 테스트는 많은 범위를 커버하는만큼 유지보수가 굉장히 힘들다는 것을 명확하게 인지해야한다.
+작은 UI 수정에도 전체 테스트가 깨질 수 있기 때문이다.
+
+최근 지원서 제출하는 기능에 테스트를 고민한 경험이 있다.
+명확한 마감 기한에 따른 유저의 제출 실패 여부가 조직에 대한 신뢰 문제로 연결될 수 있기 때문에 테스트가 있으면 좋겠다고 판단했다.
+그렇다면 어떤 테스트가 적절할까?
+최종 제출까지 여러 조건들과 API 호출 성공여부까지 모두 중요한 하나의 큰 과정을 생각하면 e2e 테스트가 필요해보인다.
+하지만 책에서 말하듯 득실 관계를 판단해야한다. 아래 질문에 대해 스스로 생각해 보는 시간을 가져본다.
+
+- 하나의 text field가 추가된다면 테스트가 깨지지 않는가?
+- 그렇다면 그 테스트를 다시 기능과 매칭시키기 위해서는 어떻게 해야할까?
+- 테스트 추가 과정을 자동화할 수는 있는가? 그 비용은 없는가?
+
+이렇게 생각하면 결코 e2e만이 정답은 아니라고 판단이 된다.
+주변 현업 개발자들의 의견을 들어봐도 해당 e2e테스트의 유지보수를 꽤 큰 비용으로 바라보고 있고, 이 코드와의 일치를
+자동화하는 것에 대해서도 많은 고민이 필요한 것으로 보인다.
+
+결국 선택의 문제인 것 같다. 조직의 규모, 해결하려는 문제 등을 전부 따져보고 적절한 테스트를 고르는 것이 시작이라고 생각한다.
+
+## 테스트 작성 연습에 대해
+
+가장 좋은 시작은 책에서 언급하듯 오픈소스의 테스트 코드를 많이 읽어보고 파악하는 것이다.
+나름의 체계를 갖춘 규모가 있는 오픈소스의 테스트 코드를 보며 작성방법과 선택을 파악할 수 있다.
+
+오픈소스를 뜯어보는 나만의 규칙은 아래와 같았다.
+
+1. 공식 문서 quick start 문서로 주 기능 파악
+2. 전체 구조 파악 (아키텍쳐)
+3. 기능 코드 흐름 파악 (추상화된 높은 레벨의 함수 등)
+4. 그 구현을 내부 동작 파악 (실제 낮은 레벨의 구현 코드)
+
+이 전체 흐름을 파악하는데 있어 테스트 코드를 먼저 파악해보는 습관을 들여보면 좋을 것 같다.
+어떤 기능을 가졌는지, 어떠한 엣지 케이스를 고려하는지 등 파악에 테스트 코드가 큰 도움이 될 것 같다.