TDD 일주일 사용 후기


최신 기술 혹은 유행하는 패러다임을 프로젝트에 적용하는 데에는 한계가 있다고 생각하는 편이다. 가용가능한 자원을 잘 고려해야 하고, 얻을 수 있는 실질적인 이득에 대한 판단이 선행되어야 한다고 생각한다. 음. 이런 경우에 경험이 많지 않은 주니어 개발자에게 스택을 "잘" 고려한다는 것은 쉽지 않은 일이라고 생각한다. 따라서 프론트엔드 분야에서 어느정도 인지도가 쌓여가는 스택이나 기술들에 대해서도 (e.g. redux) 신규 프로젝트에 무조건 도입하는 것을 지양했고, 테스트의 경우에는 개인적으로 몇 번 시도해본 경험이 전부다.

최근에 회사에서 테스트 주도 개발을 읽고 이야기를 나누었다. 프론트/백엔드를 떠나서 적용할 수 있다면 적용하는 것이 좋다는 생각이 들었따. 다만 '프론트엔드는 TDD 하기가 사실상 어렵다'고 언급하며 얼추 자리가 끝이 났는데, 유튜브에서 추천 알고리즘으로 프론트엔드에서 TDD가 가능하다는 것을 보여드립니다 를 보게 되었다. 예전에 enzyme을 사용해 snapshot test를 해보며 '이거 대체 왜 하는거고 의미가 있는건가' 라는 생각이 자연스레 지워지면서 해봐도 괜찮을 것 같다는 생각이 들었다.

React testing library

앞서 언급한 영상에서는 React testing library를 사용하고 있었다. 공식문서와 페이스북 팀에서도 권하고 있는 테스팅 라이브러리다. 라이브러리의 주요 철학은 유저 상호작용을 테스트 하는 것 에 있다. 구현 세부사항(e.g. state, lfecycle, child component)등은 테스트 내용에 직접적으로 포함하지 않을 것을 권하고 있다. (라이브러리 서문). 최근에는 TDD 중에서도 유저와의 상호작용에 초점을 맞춘 BDD(Behavior Driven Development)방법으로 테스트를 진행하는 것 같았다. React testing library를 사용하면 BDD를 구현할 수 있다고 생각했다.

어려웠던 점

일주일 간 되도록 테스트 주도 개발을 활용해 어플리케이션을 구현하려고 노력했다. 몇 번의 지키기 어려웠던 순간들이 있었다. 테스팅 라이브러리 자체에 미숙하다 보니, 실제 구현 코드로 테스트 코드를 테스트 해야 하는 기이한 현상이 발생했다. 더해서 구현 세부사항에 필요 이상의 시간(노력)이 요구되는 경우가 많았다. 특히 material ui 와의 조합이 그닥 좋지 않다고 생각했다. getbyText 등의 api를 사용해 element를 쿼리하는 경우 생각한대로 작동하지 않는 경우가 많았다. 예시로 <Select> 컴포넌트를 테스트 하는 경우 최상단 HTML Element에 <input> 혹은 <div>로 구현되어 있는 경우가 많아 직접적인 HTML 요소에 id를 설정 하기도, 쿼리하기에도 쉽지가 않았다.

장점

회사에서 진행하고 있는 프로젝트에서 바로 테스트 작성을 시도했다. 위에서 언급 했던 것 처럼 머터리얼 UI와 함께 사용하다 보니 다양한 에러가 발생했고 테스트 라이브러리 자체에 미숙하다 보니 비동기 관련된 에러와 경고사항이 콘솔에 계속 발생했다. 어디서부터 어떻게 잘못 된 건지 몰랐다.

할 일 목록을 TDD로 구현해보니 테스트 주도 개발을 지속 해봐야 겠다고 생각했다.

테스트를 만들다 보니, 컴포넌트를 어떻게 만들어야 테스트에 용이할 지에 대한 생각을 많이 하게 되었다.

더 구체적으로 이야기하면, 크게 와 닿지 않았던 여러 권고 사항들 (e.g. contatiner/presentational component를 구분하는 것_도 presentational component에서는 뷰 로직만 담고 있는 것이 프로젝트를 유지/보수하는데 도움이 된다는 생각이 명확해졌다. 테스트 하기에도 편하고, 테스트가 편하다는 이야기는 미래의 작성자나 다른 사람에게도 이해하기 쉬운 코드라는 것을 의미한다. 여튼 테스트를 작성하는 것은 생산성, 안정성과 직결된다는 것을 느낄 수 있었던 경험이었던 것 같다.

테스트 작성이 생각보다 어렵지 않다. (시간이 오래 걸리지 않는다)

의외로 괜찮게 느껴졌던 부분은 100개의 테스트 코드를 모두 처음부터 끝까지 작성 할 필요가 없다. (어느정도 복붙이 가능하다). UI에 반영되어야 하는 몇 가지 주요한 사항(update, create, get)을 파악하면 작성했던 테스트를 수정하여 경우나 예외를 테스트 하는 것은 빠르게 작성할 수 있다.

리팩토링에 부담이 전혀 없다.

기능을 개발하는 도중에 요구사항이 변경되어 코드를 수정 할 필요가 있었는데 테스트가 실행되어 다른 기능 테스트를 하지 않아도 괜찮았다. 시간을 많이 아낄 수 있었다.

일주일정도 TDD를 시도해봤는데 관성적으로 잘 안풀릴 때면 UI나 비즈니스 로직을 먼저 개발하고 싶은 충동(?)이 든다. react-testing-library, 테스트를 어떻게 효율적으로 작성할 수 있을지 등 배우고 생각할 것들이 꽤 있어 보인다. 충동을 잘 다스려 조만간 효율적인 테스트를 작성하는 방법에 대한 글을 쓸 수 있었으면 좋겠다.

반복의 느린 變化
oowgnoj github
© 2022, by oowgnoj