테스트 기법을 나열하고 끝내는지, 설계 원칙과 유지보수 트레이드오프까지 보는지를 가른다. 테스트 편의와 설계 단순함이 충돌할 때 어디서 멈출지 기준을 가졌는지가 핵심이다.
테스트하기 쉬운 코드는 입력이 명확하고 외부 의존이 분리돼 있어 결과를 예측할 수 있다. 순수 함수는 동일 입력에 동일 결과를 보장해 단위 테스트가 단순해지고, 책임이 하나로 좁혀진 모듈은 실패 원인을 빠르게 좁힌다. 반대로 UI 조작, 네트워크 호출, 전역 상태 접근이 한 함수에 섞이면 테스트 설정이 복잡해지고 작은 변경에도 깨진다. 단 테스트 편의를 위해 캡슐화를 무너뜨리거나 구조를 과하게 쪼개면 오히려 코드 품질이 떨어지므로, 테스트 용이성은 설계 단순함과 함께 본다.
비즈니스 로직을 컴포넌트 밖으로 빼서 단위 테스트가 가능해진 경험이 있다면 책임 분리의 효과와 연결할 수 있다
flaky 테스트 원인을 외부 의존 분리 부족으로 진단해본 경험이 있다면 의존성 주입의 필요성과 연결할 수 있다
테스트 편의를 위해 구조를 비틀었다가 되돌린 경험이 있다면 설계 단순함과 테스트 가능성의 균형으로 풀 수 있다
아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.