개요

테스트는 소프트웨어의 품질을 보증하는 작업 중 하나이다.

테스트 코드를 작성하는 것을 통해 버그를 조기에 발견하고 견고한 소프트웨어를 만들 수 있으며 반대로 테스트 코드를 작성하지 않으면, 변화가 발생할 때마다 모든 케이스를 고려하는 번거로움이 생기며 유지보수가 어려워진다.

Practical Testing 강의에서 테스트 코드를 작성하는 방법과 접근법을 알아보는 시간을 가진다.

테스트하기 어려운 코드

3주차에는 테스트 프레임워크인 JUnit5을 이용해 자동화된 테스트, 테스트 케이스 세분화(해피케이스와 예외 케이스)하는 작업부터 시작한다.

우빈님이 강의에서 가장 중요하다고 언급한 '테스트하기 어려운 영역 분리'가 가장 기억에 남는데, 현재 날짜와 시간, 랜덤한 값, 전역변수, 사용자 입력과 같이 관측할 때마다 '다른 값에 의존하는 코드'와 표준출력, DB 기록, 메시지 발송과 같이 '외부에 영향을 주는 코드'와 같이 어려운 영역을 분리하는 것이다.

코드에서는 메서드 내에 선언한 LocalDateTime 때문에 특정 시간에만 성공하고 나머지는 실패하게 되는데, LocalDateTime을 파라미터로 받도록 외부로 분리하는 과정을 통해 이를 알아봤다.

핵심은 테스트 하고자하는 영역을 확실히 구분하고, 이를 구분하는 시야를 길러야 한다는 것!

계층형 아키텍처에서 테스트

계층형 아키텍처는 역할과 관심사에 따라 분리한 아키텍처로 각 계층은 애플리케이션에서 화면 표시나 비즈니스 로직, DB 작업 등 관심사에 따라 분리된다.

3주차 권장 진도가 Business Layer에서 멈춰 흐름이 끊기는 느낌이어서 Presentation Layer까지 학습했다.

흔히 사용되는 아키텍처로 각 계층별 역할과 어떤 테스트를 해야하는지 알아봤는데

클라이언트 요청을 받는 순서대로 정리해봤다.

'Presentation 계층'은 사용자의 요청을 받아 처리하는 레이어로 주로 HTTP 요청/응답과 관련된 로직을 포함한다. 때문에 클라이언트가 보내는 HTTP 요청을 실제로 테스트하고 엔드포인트가 의도대로 동작하는지 확인

'Business 계층'은 도메인 객체를 활용한 다양한 처리 과정을 포함하며 데이터 접근 및 처리 로직을 포함하지 않으며, 트랜잭션을 보장해야 한다. 비즈니스 로직을 독립적으로 테스트하며 데이터 접근 레이어인 Repository나 외부 API는 Mocking하여 순수한 비즈니스 로직이 예상대로 작동하는지 검증

'Persistence 계층'은 Database나 외부 API와의 통신 등을 처리한다. 테스트에서는 쿼리 메서드가 올바르게 동작하는지, 데이터 저장 및 조회가 정상적으로 수행되는지 확인

미션 Day12

미션에서는 Readable code에서 다뤘던 코드 중 하나인 스터디 카페 이용권 시스템으로 테스트 코드를 작성하게 되었다.

코드를 작성하는데 큰 어려움은 없어서 미션을 제출하고 다른 지원자들이 작성한 코드를 살펴봤는데 Mock을 사용한 코드도 있었다. 개인적으로 classicist 쪽에 가깝기 때문에 실제 객체 사용이 어렵지 않다면 테스트 더블을 사용하지 않는 쪽인데 다양한 관점을 볼 수 있어 많이 배울 수 있었다.

맺음

테스트 코드의 중요성은 말해 입아프다. 이제 한 주 남았는데 완주 이상으로 얻을 수 있도록 노력해야겠다.

러너들 화이팅~