테스트 코드는 반드시 작성해야 될까?

 처음 리액트로 프로젝트를 진행할 때에 테스트 코드가 필요가 없었다. 작은 프로젝트나 유지보수, 서비스가 되지 않는 포트폴리오용 프로젝트를 진행하면서 많은 사람들이 가질 수 있는 생각이 '왜? 굳이? 테스트 코드를 작성해야되지?'라는 부분일 것이다.

 

 나도 부트캠프를 하고 마지막 보드게임을 만들고 한달간 보드게임에 대한 유저의견 반영 및 성능 최적화를 진행하면서도 '테스트 코드? 필요없는데?' 라는 생각을 했던 것 같다. 하지만 이번 회사를 다니면서 절실히 깨달은 것이 두가지가 있는데 첫번째는 테스트 코드의 필요성, 그리고 두번째는 리팩토링의 필요성이었다. 이전에 내 생각에도 적었다싶이 워크플로우가 막장에 가까운 회사였고 개발문화가 정착이 되어 있지 않은 회사이다보니 문제점이 많았다.

 

 그 중 가장 큰 문제는 대표의 변덕! 즉, 수시로 변하는 MVP와 UI(화면설계)들이었다.

 두번째는 솔루션 회사이다보니 클라이언트의 컨텐츠에 대한 검수에 따른 컨텐츠 업데이트와 기능 변경이었다.

 즉 기능들이 처음에 내가 설계하고 개발할 때와는 달리 변경되고 화면구성 또한 달라지다보니 재사용되는 많은 컴포넌트들이 각자의 자리에서 그 기능이 잘 동작하는지 보장되지 않는다는 것이었다. 크지 않은 부분이 변경되면 문제가 없지만 데이터가 바뀌고 로직이 변경되어야 할 때면 추가되는 기능이 잘 구현되더라도 이전 기능이 물음표가 찍히곤 했다. 

 만약, 내가 기능 구현을 하면서 테스트 코드를 작성하였다면 이후에 어떤 기능이 추가되고 변경되더라도 변경사항으로 인해 이전에 기능구현했던 부분에 어떤 의존성이 있고 어느 부분을 고쳐야할지 명확히 알 수 있었겠지만, 각 기능을 분리해서 작성하려고 했어도 완전한 순수함수들만으로 작성되지는 않았기에 이러한 경우에서 발견된 예상되지 않은 output은 찾는데에도 시간이 걸렸고 수정하는데에도 시간이 소모되었다.

 

 테스트 코드의 좋은 점은 나의 경험을 통해서 이야기 한 것과 같이 리팩토링을 하는 과정에서 내가 구현한 기능들이 정상적으로 동작하는지에 대한 보증수표가 되는 것, PM이나 대표의 요구에 의해 기능을 추가하고 변경되었을 때 기존에 동작하는 기능들에 대한 보증수표가 되는 것이라고 생각이 들었다.

 

 이러한 필요성을 갖고 공부를 시작했던 jest에 대해서 간략하게 글로 작성해보겠다.