문제 관측기능을 개발하다 보면 이런 고민을 자주 하게 됩니다:“이 흐름이 맞는 걸까?”“클래스 구조는 어떻게 나누지?”“요구사항이 막연해서 테스트를 어디서부터 시작할지 모르겠다…”예전에 작성했던 글 “TDD, 어디서부터 시작해야 할까?”에서도 저는 이런 질문을 던졌습니다:“E2E 테스트부터 시작해야 할까? 단위 테스트부터 시작해야 할까?”“기능이 머릿속에는 있는데, 테스트나 설계로 어떻게 쪼갤 수 있지?”결국 제가 느낀 건 하나였습니다:기능 구현보다 먼저 "설계를 위한 설계"가 필요하다.다양한 시도: 요구사항 명세부터 시작한 설계 실험이번에 이커머스 서비스를 설계하며 저는 "설계 자체를 목적으로 한 설계 실험"을 해봤습니다.그 중심에는 요구사항 정의 → 흐름 시각화 → 구조 설계 → 데이터 설계가 있었습..

한줄 요약처음부터 테스트를 완벽히 분리하려 하지 않고, E2E → 통합 → 단위 테스트 순으로 점진적 리팩토링을 진행하며 기능 흐름 중심의 TDD 루틴을 만들었다.실무에서는 테스트 책임을 스스로 정해야 하며, 이를 설계하는 감각이 중요하다는 점을 깨달았다.들어가며 – 개념과 실전 사이의 간극TDD(Test-Driven Development)는 익숙한 개념이었다.하지만 요구사항을 분석하고, 테스트를 먼저 작성하며 개발하는 실전 경험은 처음이었다.처음엔 이런 고민이 가장 컸다“테스트를 어떤 기준으로 나누고, 어떤 순서로 작성해야 할까?”실습에서는 테스트 유형이 과제로 주어졌기 때문에, 예를 들어 "이 기능은 단위 테스트로, 저 기능은 통합 테스트로 작성하세요" 같은 명확한 지시가 있었다.그래서 테스트 책임을..