김현욱 5주차 학습일지

테스트 전략

도메인 혹은 비즈니스 로직의 단위테스트는 기본적으로 전부 작성한다는 생각으로 진행합니다.

단위 테스트

해당 클래스의 로직이 정상적으로 동작하는지에 대한 테스트입니다.
로그인과 관련된 비즈니스 로직에 대한 단위 테스트를 예시로 들겠습니다.
비즈니스 로직은 아래와 같습니다.
ex ) Persistence Layer에 저장된 사용자 정보와 입력 정보가 일치하는지 확인 후, 일치하면 Session에 인증 정보를 저장 후 메인 페이지로 redirect한다. 로그인 정보가 일치하지 않는다면 Exception을 던집니다.

성공 테스트

정상적인 요청이 들어오는 경우에 대한 테스트로, 요청이 잘 처리되는지에 대한 테스트를 진행합니다.

1. Given Persistence Layer에 저장된 사용자의 정보를 입력값으로 설정합니다.

2. When 사용자의 정보를 해당 비즈니스 로직의 파라미터로 넣습니다.

3. Then 비즈니스 로직을 실행한 뒤, Session에 인증정보가 잘 저장됐는지, redirect 요청이 잘 반환됐는지 확인합니다.

실패 테스트

정상적인 요청이지만, 비즈니스 로직에서 원하는 값이 들어오지 않은 경우를 테스트합니다.
이 경우에서는 사용자의 로그인 정보가 일치하지 않은 경우에 대한 테스트입니다.

1. Given Persistence Layer에 저장된 사용자의 정보와 다른 값을 설정합니다.
   이 경우에는 id 값이 다른경우, pw 값이 다른경우, id와 pw값이 다른경우에 대한 입력값을 설정합니다.

2. When 일치하지 않는 사용자의 정보를 해당 비즈니스 로직의 파라미터로 넣습니다.

3. Then 모든 경우가 전부 Exception을 throw하는지 검증합니다. 세션에 값이 저장되지 않아야 하기 때문에 이 또한 검증합니다.

사용자의 비정상적인 요청이 들어온 경우

사용자의 비정상적인 요청이 들어온 경우를 테스트합니다.
이 경우에는 Id값, Pw값이 null 혹은 blank로 들어온 경우를 포함한 제약조건에 위배되는 경우를 설정합니다.

1. Given 제약조건에 위배되는 모든 경우를 셋팅합니다.

2. When 제약조건에 위배되는 정보를 비즈니스 로직의 파라미터로 넣습니다.

3. Then 적절한 Exception이 throw되는지 검증합니다.

단위 테스트에서 DB를 구현한 Persistence Layer와 연동을 해야할까?

저는 단위 테스트에서는 DB를 구현한 Persistence Layer와 연동을 지양합니다.
해당 Layer의 기능을 테스트를 진행해야하는데, DB의 상태에 따라 성공/실패가 결정될 수 있는 강한 의존도가 발생하기 때문입니다.
또한, 단위 테스트는 빠르게 진행되어야 하는데 DB Connection에 Cost가 많이 발생하기 때문에 속도가 느려질 수 있습니다.

따라서, 단위테스트를 진행함에 있어서 컨트롤 할 수 없는 영역에 대해서는 추상화에 의존하게 설계한 뒤, Mock 객체를 이용해서 테스트를 진행합니다.

Ex) Tomcat에서 Servlet에 제공해주는 HttpServletRequest, HttpServletResponse 객체, 시스템 시간에 의존하는 Timer 객체 등등