프론트엔드 테스트

최근 구직 중인 개발자 분과 이야기를 나누었는데요. 요즘 과제는 테스트 코드를 넣지 않으면 탈락하는 것 같고, 넣으면 통과하는 경향이 있는 것 같다는 이야기를 들었습니다. 갈수록 코드 퀄리티 중요성이 대두되면서 프론트엔드 도 테스트가 주목받는 것 같은데요. 테스트는 코드는 의도한 대로 동작한 다는 것을 보장합니다. 일반적으로 새로운 기능을 개발할 때도 있지만 기능의 추가나 변경 때문에 코드를 변경하는 경우도 많습니다. 테스트 코드의 가장 큰 장점은 코드를 수정할 때나 리팩토링할 때, 코드 수정 시 발생할 수 있는 사이드이펙트를 방지할 수 있습니다. 프런트엔드 테스트에는 크게 3가지가 있습니다. 1. 유닛 테스트. 코드의 Unit 단위를 테스트합니다. 단일 컴포넌트나 단일 서비스가 될 수 있습니다. 단위가 가장 작기 때문에 테스트의 양이 가장 적습니다. 소프트웨어 구조가 명확하지 않고 기능이 자주 변경되는 케이스에서는 추천하지 않습니다. 2. 통합 테스트. 통합된 기능을 테스트합니다. 여기서 통합이란, 유닛들 간의 데이터를 주고받는 환경을 의미합니다. 즉, 백엔드와 데이터베이스까지 전체를 통합해서 상호작용에 대해서 테스트합니다. 3. E2E 테스트. End to End 끝과 끝이라는 뜻이죠. 유저부터 백엔드 인프라까지 테스트하는 것을 의미합니다. 주로 cypress 등의 라이브러리로 브라우저 동작을 자동화하여 테스트를 진행합니다. 사용자 관점에서 테스트를 하기 때문에 시나리오가 변경되지 않는 한 코드를 변경해도 테스트를 변경할 필요는 없습니다. 다만 전체를 테스트하기 때문에 시간이 오래 걸립니다. 실무에서는 주로 Jest를 이용해 유닛 테스트를 하고, api 호출이 필요한 경우는 MSW 같은 라이브러리를 이용해서 mocking 을 통해 서버와 통합 없이도 테스트가 가능하게 만드는 전략을 가장 많이 사용하는 것 같습니다. 통합 테스트는 데이터베이스같이 다른 컴포넌트들과 실제 연결이 되어야 하고 테스트를 위한 비용이 커지니까요. 하지만 단위 테스트는 자신이 테스트할 부분을 독립적으로 테스트하기 때문에 빠르게 문제 여부를 확인할 수 있습니다.