TDD
TDD는 Test Driven Development로, 테스트 주도 개발이다.
작은 단위의 테스트 케이스를 작성하고 테스트를 통과하는 코드를 점점 추가시키면서 코드를 짜는 것이다.
테스트 코드
이제 그러면 테스트 코드가 뭔지 궁금할 수 있다.
테스트 코드는 말 그대로 작성한 코드를 실행하고 예상된 결과가 나오는지 확인하는 데 사용하는 코드이다.
테스트 코드에는 여러 종류가 있다.
(정적 테스트, )유닛 테스트, 통합 테스트, e2e 테스트가 있는데, 왜 이렇게 구분 지어 놓았을지 궁금할 수 있다.
이 테스트들은 다 테스트 대상의 범위가 다 다르다.
먼저 가장 낮은 단계의 정적 테스트부터 알아보자.
프론트엔드 개발자라면 다 아는 테스트일 것이다.
테스트 도구는 typescript와 eslint인데, 구문 오류, 타입 오류 같은 부분을 감지해서 런타임 에러를 방지할 수 있게 해준다.
그 다음으로는 유닛 테스트이다.
단위 테스트는 하나의 함수, 메소드, 클래스, 모듈 같은 것이 의도한 대로 작동하는지 테스트하는 것이다.
주어진 입력에 대해서 올바른 출력을 산출하는지 테스트하는 것이다.
이때, 유명한 테스트 라이브러리인 jest, mocha, react-testing-library 등을 사용한다고 한다.
통합 테스트는 유닛들 간 데이터를 주고 받는 환경 등을 테스트한다.
통합 테스트 아래 유닛 테스트 단계에서 테스트한 유닛들을 사용해서 한 단계 더 높은 수준에서 테스트를 하게 되는 것이다.
이때도 react-testing-library 등을 사용한다.
마지막으로 e2e 테스트인데, 시스템의 시작부터 끝까지 전체 흐름을 테스트하는 것이다.
모든 구성 요소와 해당 구성 요소의 상호 작용을 테스트하는 것이 포함된다.
이때 Cypress를 많이 사용한다.
그래서 프론트엔드도 TDD가 필요하다?
TDD를 하게 되면 테스트를 먼저 작성하게 되면서 요구사항에 더 적합한 코드를 작성할 수 있다.
또, 코드의 유지보수성을 향상시키게 된다는 장점이 있다.
한편, 코드를 작성할 때 의도치 않은 버그 같은 것이 당연히도 발생할 수 있다.
그런데 정해진 케이스들에 맞춰서 테스트를 진행하면 이런 버그들도 방지할 수 있다.
그런데 프론트엔드 개발자에게도 TDD가 필요하나?라는 의문이 많이들 들 수 있다.
백엔드 개발자들은 테스트 코드 없이는 개발하기 힘들다고 한다.
반면 프론트엔드 개발자들도 테스트 코드 없이 개발할 수 없나?라는 질문이 온다면 그건 아니라고 생각한다.
하지만, 장기적으로 본다면 유지 보수성 면에서도 차이가 분명히 있고, 예상치 못한 에러들을 사용자들이 마주하는 것이 아니라 개발자가 미리 겪고 고칠 수 있다.
그래서 가능하다면 프론트엔드 개발자도 테스트를 통해 개발하는 것이 더 좋다고 생각한다.
다만, 프론트엔드 TDD를 반대하는 사람들은 보통 운영에 쓰일 코드보다 테스트를 하는 코드에 쓰이는 비용이 큰 경우도 많아 비효율적이라고 한다.
당연히 테스트 비용은 무시 못하겠지만, 테스트를 통해 운영에 쓰일 코드가 좀 더 안전해지고 사용자가 에러를 볼 확률이 적어진다면 TDD를 도입하는 게 맞지 않을까?라는 생각이 든다.
다음 글
앞으로는 msw와 vitest를 활용해서 TDD를 배워나가는 글들을 올려보려고 한다.
세팅부터 시작해서 테스트 코드 작성까지 상세하게 써나갈 예정이다.
참고 자료
https://soojae.tistory.com/74#TDD%EC%9D%98%20%EC%9D%B4%EC%A0%90-1
https://velog.io/@couchcoding/%ED%94%84%EB%A1%A0%ED%8A%B8%EC%97%94%EB%93%9C-%ED%85%8C%EC%8A%A4%ED%8A%B8-%EC%96%B4%EB%96%BB%EA%B2%8C-%ED%95%B4%EC%95%BC%ED%95%A0%EA%B9%8Cwith-react-testing-libraryhttps://velog.io/@sssssssssy/TDD-Jest
'Frontend > TDD' 카테고리의 다른 글
| msw와 vitest에 대해서 알아보자 (6) | 2023.11.08 |
|---|
