Test 관련 이것저것..

강호수·2023년 1월 27일

test

test 파트에 대해 알아보다가 이것저것 끄적여본다...

Clean Code ‘단위 테스트’ 파트 요약

테스트 방식에 대해 알아보면서 ‘Clean Code’ 책을 잠깐 보았습니다. 간단하게 나와있는 만큼 간략하게 정리했습니다.

TDD의 법칙

실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.
컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.
현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.

→ 컴파일이 되는 실패 코드(expected answer가 다른)를 만든 뒤 그 코드를 통과하기 위한 코드를 작성하는 것

깨끗한 테스트 코드 → 가장 우선이 되어야 하는 것은 가독성이다. 잡다하고 세세한 코드를 다 없애고 진짜 필요한 자료 유형과 함수만 사용해야 한다.
테스트 당 assert 하나 ( ‘이와 같이 주장하는 사람들도 있다’ 는 뜻 )
- 장점 : assert문이 단 하나인 함수는 결론이 하나라서 코드를 이해하기 쉽고 빠르다
- 단점 : 테스트를 잘게 쪼개면 중복되는 코드가 많아진다 → 물론 @Before 을 이용한다면 중복 코드를 어느 정도 제어할 수 있지만 배꼽이 더 커질 수도 있다 → 한 함수에 여러 assert 문을 넣되 최대한 줄이는 것을 목표로 하자
테스트 당 개념 하나
- 지금 프로젝트에서 쓴 방식이지 않을까 싶다..(?) → 아닌가?

F.I.R.S.T

깨끗한 테스트가 따르는 규칙

Fast : 테스트는 빨라야 한다. 빨라야 자주 돌릴 수 있고, 초반에 문제를 찾아낼 수 있다.
Independent : 각 테스트는 서로 독립적이어야 한다.
Repeatable : 테스트는 어떤 환경에서도 반복 가능해야 한다. (컴퓨터, 노트북, 등…)
Self-Validating : 테스트 스스로가 성공 또는 실패의 결과 값을 내야 한다. 즉 개발자가 직접 로그 파일을 읽게 만들어서는 안된다.
Timely : 테스트하려는 실제 코드를 구현하기 직전에 구현해야 한다. (찔림…)

코드스테이츠 40기 프로젝트 발표 영상을 보던 중 백엔드 팀장분이 발표를 하시는데, TDD 방식으로 개발을 했다고 하셨습니다. 대략 660개 정도의 테스트 코드가 만들어졌다고 하는데 슬쩍 들여다봐도 괜찮지 않을까 싶어서 가져왔다.

-> 나중에 이 링크한번 참고 해보자

현재 진행중인 프로젝트에 사용한 test 방법

API 계층과 서비스 계층을 쪼개 각각 슬라이스 테스트를 진행함

→ Mock 객체를 사용해 계층별로 끊어서 테스트 함.

( 슬라이스 테스트 안에서도 단위 테스트로 나누어서 한 것도 있는 것 같고… 복잡하네…)

@Mock mock 객체를 생성한다
@InjectMocks mock 객체를 @InjectMocks 이 붙은 객체에 주입 시킨다.

에러..?

테스트를 진행하면서 TutoringService에 관련된 무언가를 가짜 객체로 만들었다가 에러가 났었다.
개념이 제대로 잡히지 않았을 때라 그랬는데, 만약 무언가 값을 고정하고 싶다면 tutoringService로 들어가 그 안에 들어있는 tutoringRepository와 같은 것들을 mock 데이터로 만들어 주어야 한다.

@WithMockUser 위 어노테이션은 지정한 사용자 이름, 패스워드, 권한으로 UserDetails를 생성한 후 컨텍스트를 로드한다. 현재 우리 코드에서는 값을 지정하지 않았으므로 아래와 같은 기본 값을 갖게 된다.
- username : user
- roles : ROLE_USER
- password : password
Spring Rest Docs
노가다….