AI 요약관련 정보

• 프론트엔드 개발에서 테스트 코드 작성은 팀과 도메인에 따라 다르며, 어떤 팀은 거의 작성하지 않고 QA에 의존하기도 함 🧪
• 테스트 코드가 있어도 구현 변경에 따라 업데이트되지 않아 깨지는 경우가 많으며, 유지보수 부담으로 인해 방치되기도 함 💔
• 테스트 실패가 항상 문제 있는 것은 아니며, 요구사항 변경에 따른 예상된 실패일 수도 있음. 중요한 것은 테스트 내용이 실제 구현과 일치해야 함 📝
• GNB(Global Navigation Bar)와 같이 여러 팀에서 사용하는 공통 라이브러리는 테스트 코드를 꼼꼼하게 작성하는 반면, 특정 지면에서는 QA나 E2E 테스트로 보완하기도 함 🛠️
• 공통 유틸 함수에 대한 유닛 테스트 작성, PR 레벨에서 코드 리뷰를 통해 테스트 필요성을 논의하는 등 팀마다 다른 규칙을 적용함 🤝
• 잦은 기능 업데이트로 인해 라이브 환경에서 장애가 발생, 핵심 로직에 대한 리그레션 테스트 케이스를 QA에서 관리하고, 프론트엔드 테스트 자동화에 대한 고민이 깊어짐 🤔
• E2E 테스트는 유닛/통합 테스트가 잘 구축된 상태에서 핵심 비즈니스 로직(결제, 배송 등)에 집중하는 것이 효율적일 수 있음 🎯
• 유닛 테스트는 모듈 단위 테스트, 통합 테스트는 2개 이상 모듈 협업 검증, E2E 테스트는 실제 사용자 시나리오 기반 테스트로 구분할 수 있음 🧩
• 실무에서는 테스트 종류를 명확히 구분하기 어려울 때도 있으며, 가장 중요한 것은 비즈니스 로직의 안정성을 확보하는 것임 ✅
• UI 깨짐과 같은 사소한 버그는 즉시 수정하지 않고 다음 배포 때 수정하는 경우도 있으며, 결제, 포인트, 쿠폰 등 금전적 피해와 관련된 부분은 철저히 테스트함 💰
• 유닛 테스트는 함수나 클래스의 구현 자체를 테스트하는 경우가 많아 깨지기 쉬우므로, 통합 테스트를 통해 모듈 간 협업을 검증하는 것이 효과적일 수 있음 🔗
• 테스트 코드 작성 시 유저 시나리오와의 괴리를 줄이기 위해, 테스트 케이스를 통해 어떤 시나리오를 테스트하는지 명확히 파악할 수 있도록 해야 함 💡
• 테스트하기 쉬운 코드를 작성하기 위해 도메인 로직을 순수 함수로 분리하고, 핵심 도메인 규칙을 테스트하기 용이하도록 설계하는 것이 중요함 ⚙️
• 테스트를 빡빡하게 짜지 않는 경우, 코드를 지나치게 모듈화하는 것이 항상 좋은 것은 아니며, 가독성과 유지보수 측면에서 트레이드오프가 발생할 수 있음 ⚖️
• 다음 시간에는 프론트엔드 개발에서 필요한 설계, MSA, 모노레포 등 다양한 아키텍처와 인프라스트럭처 전략에 대해 논의할 예정 💬