TDD, 리액트 프론트엔드 테스트 코드 범위 정하기[20221123-TIL]

메가테라에 오고 나서 신입 개발자인 우리에게 가장 중요한 게 기대하면서도 가장 기초적인 것은 테스트 코드이다. TDD형식으로 프로그래밍을 한다라고 말을 하기에는 아직 미숙할지라도 분명 나와 동기 모두는 테스트 코드를 작성해가며 프로그래밍을 해가고 있다. 이는 백엔드 프런트엔드 모두에 해당한다.

1. TDD?(Test Driven Development)테스트 주도 개발

한 문장으로 설명하기는 어렵지만 TDD란 반복 테스트를 이용한 소프트웨어 방법론으로 작은 단위의 테스트 케이스를 작성하고 이를 통과하는 코드를 추가하는 단계를 반복하여 구현하는 방식이다.

이로써 처음에는 작은 단위로서의 green들이 리팩토링을 통하여 더 나은 코드가 되고 또한 코드의 작동성 또한 검증해나가면서 개발을 해나간다고 할 수 있다.

TDD가 어려운 점이라면 사실 우리는 메가테라의 시작부터 아샬 님의 강의를 따라 테스트를 치며 코드를 치는 연습을 했기 때문에 딱히 잘 느끼지 못한다. 굳이 꼽자면

 

1. 어떤 방식으로 테스트 코드를 작성하며 본 코드를 작성하고 수정해나갈지 처음에는 감이 잘 잡히지 않는다.

2. 테스트 코드에 쓰이는 다른 코드들을 익히고 사용법에 익숙해져야한다.

3. 테스트 코드를 통해 내가 구현한 코드가 검증되는지 확신이 들지 않는다.( 테스트 코드 사용의 미숙)

4. 처음에는 생산성이 낮다.(테스트 코드 사용의 미숙에서 비롯)

 

그런데 습관처럼 계속하다 보면 처음에는 확신이 들지 않다가 이 테스트를 프로젝트 단위로 가져와서 백엔드와 프런트를 모두 아우르면 테스트 코드의 힘이 나온다. 테스트가 통과된다면 굳이 console.log 와 system.out.println으로 임시방편적인 검증을 계속할 필요가 없고 백엔드 서버나 프런트 서버가 만들어져있지 않다고 하더라도 작성한 코드를 검증할 수 있다.

또한 생산성 또한 장기적 측면에서 증가하는데 아무리 간단한 프로그램이라고 하더라도 오류가 나는 순간부터 디버깅 포인트의 변수는 약 무한대가 되는데... 이를 유한을 넘어 어디서 오류가 나는지 파악과 검증해주는 것이 테스트 코드이다. 이것이 단기적 장기적 관점에서 생산과 유지보수에 얼마나 도움이 되는지는 생략한다.( 물론 콘솔 로그와 시스템 아웃 프린트를 사용하면 무한대의 경우가 유한해지지만 사실 이것도 그냥 눈 감고 소발에 쥐잡기와 마찬가지이다.)

 

2. 프런트 엔드에서의 테스트 코드를 왜 짜야하나?

이렇게 되지 않으려면 짜야지 ^^

처음에는 프런트엔드 단위에서 테스트 코드를 짠다는 것이 생소했다.

일단 자바에 익숙해진 터라 자바스크립트로 테스트를 하는 것이 어려웠는데 그것을 또 복잡한 테스트 단위로 옮겨가니 부하가 너무 컸다. 그런 상태에서 코드를 치면 화면에 나타나는 프런트라서 더욱 테스트를 왜 짜야하는지 니즈를 못 느꼈었다. 그러나 테스트 코드가 없는 코드를 어찌 검증할 거냐는 트레이너님의 말을 듣고 한번 재고해보다가 이것 또한 프로젝트 단위로 옮겨가며 더 필요성을 느끼기 시작했다.

 

1. API 서버에서 넘겨오는 데이터를 처리하는 것은 어떻게 검증할 것인가.

2. 반대로 프런트에서 데이터를 전송해줄 때는 이것을 어떻게 데이터가 잘 전송된다고 검증할 것인가?

3. 내가 구성한 컴포넌트에서 작동한다는 것을 화면 단위에서 말고 코드 단위에서 어떻게 검증할 것인가?

4. 화면 단위에서 작동하는 코드가 '우연히' 그 상황 속에서만 작동된 것인지 상시 작동을 보증하는지 어떻게 검증할 것인가?

(위 질문에 응? 왜? 화면에 되면 된 거잖아?라고 한다면 여러 조건의 상황에서 어떨 땐 되고 안되고라는 프런트 지옥을 경험해보지 않았을 확률이 높다.)

3. 그럼에도 프론트 엔드의 테스트 코드 작성은 어렵다.

하지만 프런트 단위에서 테스트 코드 작성은 매우 어려운데 그 이유는 일단 양이 방대하다. 화면에 있는 기능 모두를 검증해주어야하고 받아오는 라이브러리 마다 테스트하는 방식이 다른데 프론트 엔드 테스트에 대한 정보는 (특히 한국에서) 전무하다. jest 공식 홈페이지도 복잡하다.(리액트 테스트할 때 쓰는 라이브러리)

그리고 기능이 작동되면 테스트를 짜기가 너무너무 귀찮아진다. 하지만 거대한 댐도 작은 구멍에서 무너지는 거라고 이렇게 한 번 두 번 짜기 귀찮아 넘어가면 결국 테스트 코드가 없는 코드가 나온다.

 

4. 프런트 테스트의 범위 정하기

위 3번에서 말했듯 프론트 테스트 코드의 작성이 어려우나 이는 핵심 문제는 아니므로 ( 문제이긴 한데 여기서 다룰 만큼 가볍고 양이 적지 않다.) 조금 더 본질적인 것을 적어보려고 한다. 그것은 테스트의 범위를 정하는 것이다.

테스트를 하다 보면 상단 컴포넌트를 할 때와 상위 컴포넌트에 속한 하위 컴포넌트들을 모두 처리해주어야 할 때가 있다. 이때 상단에서 모든 코드를 검증해주는 것이 아니라 상단 컴포넌트는 본인이 가진 기능들만 테스트를 하고 나머지는 하위 컴포넌트의 테스트 책임으로 넘겨주어야 한다.그래야 검증해야 할 책임이 잘 나눠진 테스트가 된다. 그렇지 않으면 테스트를 위한 중복 테스트가 될 뿐이다.

또한 테스트의 범위를 정해야 한다. 즉 모든 요소들을 테스트하는 것이 아니라 내가 검증해야 할 부분들이 테스트에서 검증이 되고 나머지도 된다는 확신이 있다면 자신만의 논리를 가지고 생략해도 되고 그렇지 않은 경우에는 전부 검증해도 된다. 이는 오로지 개발자의 역량과 논리에 달려있다. 따라서 라이브러리는 라이브러리 자체를 신뢰해야 하므로 테스트를 따로 진행하지 않고 모킹만 해주는 것처럼 내가 만든 코드에서 검증해야할 것의 논리와 이유를 가지고 그에 맞는 테스트를 작성한다.

무작정 저어어언부 라고 작성하지 않는다.

(근데 하다 보면 늠)