[TIL] 내일배움캠프 42일차 - 테스트 코드

 

 

오늘의 학습 키워드📚

좋은 테스트란

테스트 코드 개인 과제가 끝이 났다. 검토해보면 난 절대 좋은 테스트를 작성하지 못했다고 생각한다.

좋은 테스트란 과연 뭘까.
Mock 라이브러리를 잘 활용해서 테스트 코드를 작성하는 것?
다양한 테스트 프레임워크를 사용해 테스트를 해보는 것?

그냥 간단하게 '테스트의 행위가 의도한 대로 완수되는지'가 좋은 테스트이다.
무슨 요청을 해서 값이 이렇게 들어가면 어떻게 처리가 돼서 이렇게 나와야 되고 1이라도 틀리면 안되고 응답 메세지는 반드시 이렇게 나와야 하고...
물론 목적에 따라 값의 아주 세밀한 검증이 요구될 수 있고 응답에 대한 메세지의 검증이 필요할 수 있다.
하지만 결론은 어떠한 목적으로 테스트를 진행했으며 테스트의 행위가 의도한 대로 동작했는가?를 가장 중점으로 봐야 한다는 것이다.

// Method
int add(int a, int b) {
	return a + b;
}

// Test
@Test
void addTest() {
	assertEquals(add(1, 1), 2);
}

위의 테스트는 좋은 테스트일까?
난 아니라고 생각한다. 그냥 테스트 커버리지를 채우기 위한 의미 없는 행위라고 생각한다.
누가 봐도 명확한 값이 나오는 메소드를 굳이 테스트하는 것은 좋지 않다고 생각한다.

// Method
int addAndParseLong(int a, int b) {
	return (long)(a + b);
}

// Test
@Test
void addTest() {
	assertEquals(addAndParseLong(1, 1), 2L);
}

하지만 이렇게 int를 더해서 Long으로 형변환이 잘 되는지를 테스트한다면?
당연히 1 + 1 = 2가 Long 타입으로 변환돼서 잘 나오겠지 라는 생각은 있지만 시스템적으로 파싱이 됐을 때 과연 완벽히 일치하는 값인가에 대한 테스트는 진행할 필요가 있다.
어쩌면 1 + 1을 더해서 Long으로 변환했는데 더미 값이 생겨서 2.000000000000000.....000001이 될 수도 있다.

어떤 메소드를 테스트할 때는 목표를 명확히 하는 것이 좋은 테스트란 것이다.
이 메소드를 실행해서 하나부터 열까지 전부 완벽히 수행되어야 통과되는 테스트? 좋지 않다.
너무 결괏값이 명확한데 굳이 진행하는 테스트? 좋지 않다.

단위 테스트에서 Controller의 어떤 POST 메소드에 대한 테스트를 진행하고자 하면 목표를 정확히 해야 한다.
'요청이 잘 가고 응답이 200으로 잘 오나?'
그럼 요청하고 응답받은 값에 대한 테스트보다는 요청해서 응답이 200으로 잘 오는지만 테스트하면 된다.
User를 넘겨서 Service에서 지지고 볶아서 ResponseDto를 응답으로 받아와서 어쩌구저쩌구 하는 건 중요하지 않다. 결국 요청이 잘 넘어갔고 응답이 잘 오는지만 테스트하면 된다.

---

오늘의 회고💬

팀 프로젝트를 시작해서 하루 종일 회의만 한 것 같다. 마지막에 테스트 코드에 관한 강의를 들어서 그냥 느낀 점을 두서없이 막 휘갈긴 것 같다.

 

내일의 계획📜

주말 동안 틈틈이 팀 프로젝트를 진행해야겠다.