즐겁지 않은 코딩
즐겁지 않은 코딩을 즐거움으로 승화시키는 꼼수를 정리했다.
코드를 테스트하기 쉬운 구조로 변경하기
단위 테스트도 중요하지만 그 전에 함수를 테스트할 수 있는 모양으로 만드는 것이 더 중요하다. 이렇게 하면 함수가 자동으로 리팩터링 된다. 코드가 좀 더 이해하기 쉽게 변경된다. 함수를 만든 후에 테스트를 넣는 것은 생각보다 번거롭고 함수 만들기 전에 테스트를 만드는 것은 어렵다. 지금 보고 있는 함수가 따로 분리해서 테스트하기 힘든 구조라는 생각이 든다면 코드는 이미 복잡하다. 어떻게든 테스트할 수 있는 구조로 만들어야 한다. 딱 요런 구조로만 만들어도 코드 이해하기가 쉬워진다.
컴포넌트를 분리하여 미리 보기
프런트엔드 개발의 경우 컴포넌트라는 개념을 사용한다. 함수보다는 조금 더 코드가 많고 UI를 포함한다. 이 컴포넌트도 단위 테스트를 할 수 있지만 그전에 우선 컴포넌트만을 분리해서 미리 보는 방법이 좋다. 자동 테스트는 아니지만 수동 테스트를 도와준다. 여러 값들을 미리 넣어 볼 수 있다. Storybook을 사용하여 컴포넌트를 분리했더니 컴포넌트로서 부족한 부분이 여럿 발견되었다. 컴포넌트 혼자만 표현하는 기회가 없어서 문제를 발견하지 못했다. 이 컴포넌트를 다른 코드에서 사용했다면 그때 문제를 발견할 것이다. 컴포넌트에 전달되는 값을 쉽게 변경할 수 있음으로 테스트 도구로 좋다. 스토리를 먼저 만들고 컴포넌트를 만들어 기능을 확인하고 그다음에 이 컴포넌트를 사용한다.
고객 테스트를 자동화 하기
컴포넌트를 미리 보면서 버그를 수정해도 시나리오 관점에서 문제가 발생할 수 있다. 고객 관점에서 테스트를 할 수 있는 Cypress를 사용하고 있다. 로그인이 잘 되는지 두 번째 서브 메뉴를 선택했을 때 메모 목록을 잘 표시하는지 등을 테스트할 수 있다. 브라우저를 사용하여 테스트 과정을 지켜볼 수도 있고 브라우저 없이도 테스트 가능하다. 시나리오 의존적임으로 시나리오가 자주 변경되는 부분보다는 주요 기능을 테스트하는 것이 좋겠다. 테스트 과정을 코드로 기술하기 때문에 함수처럼 재 사용할 수 있다. 데브옵스가 배포를 자동화하는 것처럼 Cypress를 사용하여 고객 대상 테스트를 자동화할 수 있다.
이런 방법이 좋은 이유
단위 테스트나 컴포넌트를 테스트를 하지 않고 이런 비켜가는 것처럼 보이는 어중간한 방법을 사용하는 이유는 가성비가 좋아서다. 단위 테스트와 콤포넌트 테스트는 생각보다 어렵고 시간이 너무 많이 들고 그 중간쯤에 재미를 읽어 버리기 일쑤기 때문이다. 코드를 조금 변경하고 컴포넌트를 미리 보는 작업이 더 쉽다. 어렵고 힘들면 오래 할 수 없다. 디자이너에게는 Storybook을 보여주고 기획자에게는 Cypress를 보여주면서 같이 일하는 나를 상상할 때 즐겁다.
