3주차 수업은 드디어 기다리던 테스트 코드 작성이었습니다. 사실 처음에는 강의를 들었음에도 불구하고 테스트 코드를 어느 파일에 어느 내용을 어떤식으로 작성해야 하는지 막막한 느낌이 강했던 것 같습니다. 우선은 강의 내용을 참고해서 최대한 유사한 구조를 가져가려고 노력하며 첫 pr을 작성했고 이후 리뷰를 받으면서 모호했던 부분들에 대해 하나하나 감을 잡아가는 한 주 였던 것 같습니다:)

BDD

BDD는 소프트웨어 개발 방법 중 하나로 Behavior Driven Development 즉, 행위(시나리오, 명세)를 기반으로 테스트 자체가 요구사항이 되도록 하는 개발방법입니다.

Given, When, Then 의 패턴으로 비개발자도 이해할 수 있을 정도의 구조로 코드를 작성합니다.

컴포넌트를 개발할 때 ‘이 컴포넌트는 어떤 상황에서 어떻게 동작한다’ 라는 내용을 외부에 노출된 인터페이스 수준에서 기술하고, 리팩토링 등을 통해서 수시로 변경될 수 있는 구체적인 내부 동작은 테스트 코드에 포함되지 않도록 작성할 필요가 있다고 느꼈습니다.

몇 차례 피드백을 받아 결과적으로는

- 어떤 상황에서 어떤 컴포넌트가 렌더하면 어떤 뷰를 렌더링한다.
- 어떤 상황에서 어떤 이벤트가 발생하면 어떤 인터페이스가 호출된다.

라는 느낌으로 테스트코드를 작성하게 되었고, 테스트를 실행했을 때 작성했던 테스트의 이름들 만으로도 해당 테스트가 어떤 목적으로 어떤 부분을 테스트 하는지 명확하게 읽힐 수 있도록 했습니다.

중복되는 render 함수 호출과 필요한 props를 컴포넌트에 넘겨주는 작업은 외부 함수로 추출해서 중복을 줄여주었습니다.

또 React API인 useState나 props로 넘겨주기 위해 필요했던 event handler 함수들은 jest를 사용해 mocking하고, 매 테스트가 실행될 때마다 초기화해주는 clear 함수에 대해서도 배울 수 있었습니다:)

useState를 mocking하는 부분이 다소 어려웠는데, 특정 라이브러리에 의존적인 코드는 해당 라이브러리를 mocking해야 테스트가 가능하기 때문에 테스트 코드의 복잡도가 다소 올라간다는 느낌을 받았습니다.

코드를 작성할 때 React를 포함하여 외부 라이브러리에 의존적인 코드와 그렇지 않은 코드를 잘 추상화한 다음 레이어를 분리하여 관리해봐야겠다는 생각이 들었던 한 주였습니다.

--

--