개발을 진행하면 진행할 수록 테스트를 해야하는 범위가 늘어날뿐더러 인력도 같이 늘어남 - 커버할 수 없는 영역이 발생 - 경험과 감에 의존 - 늦은 피드백 - 유지보수에 대한 어려움 - 소프트웨어의 신뢰도 하락
빠른 피드백, 자동화, 안정감을 위해 테스트코드를 작성
테스트코드를 작성하지 않는다면 - 변화가 생기는 매순간마다 발생할 수 있는 모든 Case를 고려해야 함 - 변화가 생기는 매순간마다 모든 팀원이 동일한 고민을 해야 함 - 빠르게 변화하는 소프트웨어의 안정성을 보장할 수 없음
테스트코드가 병목이 된다면 - 프로덕션 코드의 안정성을 제공하기 힘들어짐 - 테스트 코드 자체가 유지보수하기 어렵고 새로운 짐이 됨 - 잘못된 검증이 이루어질 가능성이 생김
올바른 테스트코드란? - 자동화 테스트로 비교적 빠른 시간 안에 버그를 발견할 수 있고, 수동 테스트에 드는 비용을 크게 절약할 수 있음 - 소프트웨어의 빠른 변화를 지원 - 팀원들의 집단 지성을 팀 차원의 이익으로 승격시킴 - 가까이 보면 느리지만, 멀리 보면 가장 빠른 방법
단위 테스트(Unit test) - 작은 코드 단위(클래스 or 메서드)를 독립적으로 검증하는 테스트 - 검증 속도가 빠르고 안정적
JUnit5 - 단위 테스트를 위한 테스트 프레임워크 - XUnit - Kent Beck ㄴ SUnit(Smalltalk), JUnit(Java), NUnit(.Net) 등
AssertJ - 테스트 코드 작성을 원활하게 돕는 테스트 라이브러리 - 풍부한 API, 메서드 체이닝 지원 - JUnit과 같이 쓰임
테스트케이스 세분화 - 암묵적이거나 아직 드러나지 않은 요구사항이 있는가? - 해피 케이스 - 예외 케이스 - 경계값 테스트가 매우 중요(범위(이상, 이하, 초과, 미만), 구간, 날짜 등 ㄴ 경계값이 존재할 경우 경계값에 대한 테스트를 하는 것이 중요!
테스트하기 어려운 영역을 구분하고 분리하기
테스트하기 어려운 부분
테스트 하기 어려운 부분을 외부에서 받도록 파라미터를 분리
테스트하기 어려운 영역 - 관측할 때마다 다른 값에 의존하는 코드(현재 날짜/시간, 랜덤 값, 전역 변수/함수, 사용자 입력 등) - 외부 세계에 영향을 주는 코드(표준 출력, 메시지 발송, 데이터베이스에 기록하기 등)
순수함수(pure functions) - 같은 입력에는 항상 같은 결과 - 외부 세상과 단절된 형태 - 테스트하기 쉬운 코드
lombok - @Data, @Setter, @AllArgsConstructor 지양 - 양방향 연관관계 시 @ToString 순환 참조 문제 발생
댓글