개발에는 테스팅이 중요하다고들 말한다.
개발하기도 바쁜데 테스트 코드도 작성해야 된다고?
실행했을 때 오류 없이 잘 돌아가면 된 거 아닌가?
A 페이지와 B 페이지가 있다고 가정해보자.
어느 날 A 페이지를 수정해야 할 일이 생겼다.
수정 후 A 페이지를 확인하니 정상적으로 동작한다. 야호, 수정 끝!
그런데 다음 날, 누군가 사이트를 확인하다가 B 페이지에서 오류를 발견했다.
🐰 : "여기 B 페이지 오류 나요!"
🐹 : "B 페이지는 건든 적도 없는데요?????"
어떻게 된 일일까?
알고 보니 A 페이지와 B 페이지는 동일한 전역 상태를 공유하고 있었다.
A 페이지의 상태를 수정하면서 B 페이지에서 오류가 발생한 것이다.
🐹 : "헉, 이 상태 C 페이지에서도 사용하는데? 다 확인해봐야겠네 ㅠㅠ"
결국, 해당 상태를 사용하는 모든 페이지를 일일이 확인해야 했다. 개발 시간이 2배로 늘어났다.
테스트 코드의 중요성
만약 테스트 코드를 작성했다면 어땠을까?
🐹 : "수정 끝! 테스트 돌려보자~"
테스트 코드가 실행되면서, B 페이지와 C 페이지에 문제가 발생할 수 있음을 경고했다.
🐹 : "A 페이지의 수정이 B 페이지와 C 페이지에 영향을 주네! 다행히 미리 알았으니 수정해야겠다."
테스트 코드 덕분에 오히려 개발 시간을 줄일 수 있었다.
이렇듯 테스트 코드는 단순히 오류를 잡는 것을 넘어, 코드 변경이 다른 부분에 미치는 영향을 사전에 확인할 수 있다.
이는 개발자가 안심하고 코드를 수정할 수 있게 해주며, 예기치 못한 오류로 인한 긴급 수정을 줄여준다.
테스트 코드 작성 방법
그렇다면 테스트 코드는 어떤식으로 작성하면 좋을까?
테스트 코드를 작성하는 방법은 다양하다. 그 중 많은 사람들이 사용하는 두가지 방법을 알아보자.
테스트 주도 개발 (Test-Driven Development, TDD)
테스트 주도 개발(TDD)은 테스트 코드를 먼저 작성하고, 작성한 테스트 코드를 통과하도록 메인 코드를 작성하는 개발 방식이다.
일반적으로 아래와 같이 진행된다.
- 빈 함수, 빈 컴포넌트 등의 최소한의 메인 코드를 작성한다.
- 테스트 코드를 작성한다.
- 테스트를 실행해서, 테스트가 실패하는 것을 확인한다.
- 테스트 코드를 통과할 수 있도록 메인 코드를 수정한다.
- 테스트를 실행해서, 테스트가 성공하는 것을 확인한다.
이 방식은 코드를 작성하기 전에 요구사항을 명확히 이해하고, 이를 코드로 구현하기 쉽게 만들어 준다.
Given-When-Then 패턴
Given-When-Then 패턴은 테스트를 명확하게 구조화하는 방법이다.
이름에서 알 수 있듯이, 테스트를 다음과 같은 세 단계로 나눈다.
- Given
테스트를 수행하기 전에 테스트에 필요한 환경을 설정하는 단계이다.
테스트에 필요한 변수나 함수를 정의하거나 컴포넌트를 생성한다. - When
테스트의 목적을 보여주는 단계이다.
실제 테스트 코드를 작성하고, 테스트를 통해 결과값을 가져온다. - Then
테스트의 결과를 검증하는 단계이다.
When 단계에서 얻은 결과값을 검증하는 작업을 수행한다.
it('+버튼 클릭 시 1씩 증가', () => {
// Given
render(<App />);
const incrementBtn = screen.getByTestId('incrementBtn');
// When
fireEvent.click(incrementBtn);
// Then
const changeScreen = screen.getByText('현재 숫자: 1');
expect(changeScreen).toBeInTheDocument();
});이 패턴은 테스트 코드의 가독성을 높이고, 각 단계의 목적을 명확히 할 수 있게 해준다.
이렇듯 테스팅은 선택이 아닌 필수이며, 개발 후 추가적인 작업이 아니라 개발 과정의 일부분이다.
테스트 코드를 작성하고 이를 기반으로 개발을 진행하면, 더 안정적이고 유지보수 가능한 소프트웨어를 만들어낼 수 있다.
이는 결국 사용자에게 더 나은 경험을 제공하고, 개발자의 작업 효율성을 높이는 데 기여한다.
결론
공든 탑이 무너지랴!
기초부터 단단히, 한 번 할 때 제대로 하자 😓😓
