[후기] TDD를 체험해보자 - Newstream

최초 작성일 : 2024.09.23

최종 수정일 : 2024.09.23

 

1. 개요

'프론트엔드에서 테스트 코드가 필요가...?'라고 생각하던 때가 있었다. 백엔드와 달리 프론트엔드는 개발시 hot reloading을 통해 변경점과 기능을 바로바로 확인할 수 있기 때문이다. 하지만 서비스를 운영한지 1년이 넘으면서 생각이 바뀌었다.

서비스를 업데이트하다보면 기존 기능의 변경(추가/수정/삭제)가 아주 빈번하게 발생하고, 이러한 변경이 다른곳에 영향을 미칠 수 있는 가능성이 생기기 때문이다. 처음에는 이런 문제를 해결하기 위해 의존성을 최대한 없애는 식으로 리팩토링을 진행해 보았지만 완전히 해결될 수는 없었고 의심되는 기능들을 손으로 일일히 확인해야만 했다. 그리고 그때 이런 생각이 들었다 '아, 이런 테스트를 한번해 해줄 무언가가 있었으면 좋겠다.'.

테스트의 필요성을 체감했고 문제 해결을 위해 프론트엔드 환경에서 테스트 코드 작성, 활용 방법을 공부했다. 그리고 TDD(Test Driven Development)개발 방법론을 적용해 프로젝트를 진행하며 앞서 언급했던 문제들을 해결할 수 있을지 고민해보았다.

 

2. 프로젝트 소개

프로젝트를 시작하기 전 목적을 정했다.

1) 이 프로젝트는 TDD방법론과 테스트 코드의 효과를 느껴보기 위해 진행하는 프로젝트이다.

2) 많은 기능을 넣지 않는다. 테스트 코드의 효과를 느껴볼 수 있을 정도만 진행한다.

3) 2)번과 같은 이유로 유려한 시각효과, 최신 유행 기술 등도 적용하지 않는다. vanilla css로 최소한의 스타일만 적용한다.

4) "완벽한"서비스를 만드려 하지 않는다. TDD, 테스트 코드를 체험하는데 집중한다. 또한, coverage 100%를 목표로 하지 않는다.

 

프로젝트는 간단한 뉴스 검색 서비스로 정했다.

사용자가 검색어를 입력하면 naver의 뉴스 검색 api를 이용해 관련된 뉴스들을 제공하는 서비스이다.

서비스의 이름은 뉴스(News)와 흐름(Stream)을 합쳐 Newstream으로 정했다.

서비스는 아래의 링크에서 볼 수 있다.

https://newstream-mu.vercel.app/

Create Next App

 

3. TDD방법론 적용하기

이미지 출처 : https://developer.ibm.com/articles/5-steps-of-test-driven-development/

 

내가 이해한 TDD방법론은 다음과 같은 순서를 따른다.

1) 기능을 정의한다.

2) 기능을 테스트하는 테스트 코드를 작성한다.

3) 테스트를 진행한다. (테스트 실패)

4) 테스트를 통과할 수 있는 최소한의 기능만 구현한다.

5) 테스트를 진행한다. (테스트 성공, 실패시 4)로)

6) 코드를 정리하고, 스타일을 적용한다.

7) 1)로 돌아간다.

 

이 프로젝트도 1)~7)의 순서를 최대한 지키기 위해 노력했다.

하지만 습관적으로 기능을 먼저 만들어버리는 경우도 있었다. 이 경우 순서가 잘못되었다는걸 인지한 순간 구현을 멈추고 1)부터 진행했으나 순서가 맞지 않은 부분도 몇몇 존재한다.

 

4. 후기

본 프로젝트를 진행하며 느낀점을 정리해보았다.

• 테스트 코드 작성 및 테스트 과정이 추가되었기 때문에 기존보다 시간이 오래 걸릴것 같았다. 실제로 초반엔 시간이 오래 걸렸으나, 조금 익숙해진 뒤엔 시간 차이가 그리 크지 않았다.
• 어떤것을 mocking할지, 어디까지 테스트해야할지 고민이 많았다. naver api통신 부분은 mock데이터로 테스트하면 되는것이지만, 이 또한 테스트해야하는줄 알고 테스트 작성 방법을 고민하느라 시간을 많이 소요했다.
• navigation부분도 고민이 많이 되었다. 이 프로젝트는 Next.js로 개발됐기 때문에 서버에서 동작하는 기능은 테스트코드에선 감지할 수 없었다. 따라서 redirect부분도 mocking해야 했고, url의 변화는 테스트할 수 없었다.
• 기능 변경시 서비스의 안정성은 확실히 증가했다. pagination기능 개발할때 기존에 pass되던 기능이 갑자기 fail돼서 살펴보니 변경된 파라미터를 전달하지 않는 부분이 있었다. 테스트 코드가 없었다면 실제 웹 화면을 테스트하며 오류를 발견했을 것이고, 원인을 찾는데에만 시간이 많이 소요됐을 것이다.
• 심리적 안정성도 증가했다. 테스트 코드가 기존의 기능들을 테스트해주기 때문에 예상치 못한 예외의 두려움이 사라졌다. 과장해서 말하자면 기능개발시엔 화면을 안보고도 구현할 수 있을것 같았다.
• 테스트가 제공해주는 정보가 문제를 해결하는데 도움이 많이 되었다. 어떤 파일의 어떤 부분이 테스트되지 않고 있고, 어떤 부분에서 기대값과 실제값이 다르게 나타났는지 친절하게 알려줬다.
• "이정도 테스트코드면 충분한가?"라는 생각이 종종 들었다. 내가 생각하지 못한 부분이 있지는 않을지 고민이 많이 되었다.
• 이 프로젝트가 E2E테스트는 진행되지 않는것 같다. 테스트를 실행하면 실제 화면(웹)이 켜지고 매크로처럼 E2E 테스트가 진행할수 있는 방법은 없는지 고민되었다.

앞서 얘기했지만 이 프로젝트를 통해 나는 TDD방법론과 테스트 코드의 효과를 알아보고 싶었다. 결과적으로 테스트 코드는 내가 기대했던 기능인 안정성(기능적, 심리적)을 가져다줄 수 있다는걸 알게 되었다. 앞으로 다른 프로젝트를 진행하게 된다면 적극적으로 테스트 코드를 도입해볼 계획이다.

 

프로젝트 코드는 아래 링크에서 확인할 수 있다.

https://github.com/mooooondh/Newstream

GitHub - mooooondh/Newstream

 

도움을 받은 도서

소프트웨어 장인 정신 이야기 - 로버트 C. 마틴

프런트엔드 개발을 위한 테스트 입문 - 요시이 다케후미