테스트 코드 이론

테스트코드를 입문하기 전, 대체 왜 사용할까에 대해 강의를 듣고 정리해보았다.

 

테스트 코드의 장점

 

1. 리팩토링 시 최소한의 통과 기준을 만들어낼 수 있음

 

프론트엔드 작업을 하다보면 리팩토링을 하게되는 경우가 많은데, 이 때 예기치 못한 부분에서 버그가 발생하는 등 이슈가 발생할 수 있다.

이 때 테스트코드를 작성해 놓으면 우리가 작업한 후의 코드가 통과해야 하는 최소한의 기준을 세울 수 있다.

즉, 우리의 코드 변경으로 인해 중요한 로직이 이상하게 동작하는 것을 배포하기 전에 발견할 수 있을 것이다!

 

2. 문서화에 용이함

 

describe("회원가입 페이지", () => {
	/*
	각 항목을 jira ticket으로 생각하고 작업할 수 있음
  브랜치 별로 테스트코드 작업 가능
	*/
  test("인풋이 활성화되면 underline의 컬러가 바뀐다", async () => {  });
  test("아이디가 중복이면 에러메시지가 나타난다", async () => {  });
  test("비밀번호가 일치하지 않으면 에러메시지가 나타난다", async () => {  });
  test("회원가입에 실패하면 에러메세지가 나타난다", async () => {  });
});

 

예를 들어 위와 같이 회원가입 페이지와 관련된 테스트코드를 작성했다면, 해당 페이지의 목적이 무엇이고 어떤 동작을 수행해야하는지 명확하게 파악할 수 있다.

또한 외부 개발자가 들어오더라도 테스트 케이스를 통해 컴포넌트의 상세 구현사항을 쉽게 파악할 수 있어 협업이 수월해 질 수 있다.

 

그러면 우리는 대체 어떤 것을 테스트 하는 것이 좋을까??

 

테스트를 해야 할 것

 

우리가 만든 서비스를 사용자들이 이용할 때 문제가 없어야 함은 명확한 사실이고, 이를 위해 비즈니스 로직을 테스트 해야한다고 강의에서 나온다.

 

비즈니스 로직을 테스트 한다는 것은 ChangeEvent, ClickEvent 등의 Event를 테스트 하는 것을 말한다.

 

예시) 로그인 페이지를 테스트 한다고 할 때

• 아이디 / 비밀번호 input이 잘 입력되는지
• 버튼이 활성화 되고 클릭이 잘 되는지
• 로그인 성공 or 실패 시 적절한 액션들이 수행되는지

 

테스트하지 말아야 할 것

 

비즈니스 로직처럼 테스트가 필요한 부분이 있는 반면, 굳이 안해도 되는 부분들도 존재한다.

 

그것은 바로 margin, padding 등과 같은 UI와 관련된 것들이다.

대부분의 서비스들은 반응형으로 만들기 때문에 테스트를 하기 까다로울 뿐더러, 반응형을 하지 않는다고 해도 Storybook이라는 훌륭한 UI 테스트를 지원하는 툴이 존재한다.

따라서 테스트코드로 UI를 테스트하는 것은 그다지 효율적이지 않다.

 

다양한 유형의 테스트

 

유닛 테스트

 

유닛 테스트는 가장 작은 단위의 테스트이다.

 

로그인 페이지에서 유닛 테스트를 진행한다고 한다면 예를들어

 

• 이메일 / 비밀번호 input이 잘 입력되는지
• 버튼이 잘 클릭되는지

 

등의 테스트가 유닛 테스트에 포함된 것이다.

즉, input, button 등의 JSX 태그들을 하나하나 테스트하는 것이라고 생각하면 된다.

 

통합 테스트

 

통합테스트는 위의 유닛 테스트 결과물들이 하나로 묶여 잘 동작하는지 테스트 하는 것을 말한다.

 

마찬가지로 로그인 페이지에서 통합 테스트를 진행한다 하면 

 

• 로그인 / 비밀번호 input을 입력한 후 로그인이 잘 되는지
• 잘못된 정보로 로그인을 시도하면 에러 로직 처리가 잘 되는지

 

등의 테스트를 통합 테스트의 예로 들 수 있을 것이다.

 

e2e(end-to-end) 테스트

 

e2e 테스트는 사용자가 서비스를 실제 사용하는 것 처럼 테스트를 진행하는 것이다.

 

마찬가지로 로그인을 예로 들면

 

• 로그인 페이지에 접속하여 이메일 / 비밀번호를 이용해 로그인이 성공적으로 이루어지는지
• 로그인 페이지에 접속하여 잘못된 정보를 입력할 때 에러 로직들이 잘 수행되는지

 

를 확인하는 것이 e2e 테스트라고 할 수 있다.

 

통합 테스트와 e2e 테스트의 차이

 

사실 위에 정리한 내용들을 보면 통합 테스트와 e2e 테스트는 거의 같아 보인다. '

그럼 어떤 기준으로 두 테스트를 구분하는 걸까?

 

통합 테스트는 컴포넌트를 렌더링 후 테스트를 하고, e2e 테스트는 페이지에 접근하여 테스트를 한다는 점에서 차이점이 있다.

 

쉽게 말하면 통합 테스트는 개발자가 직접 코드를 통해 컴포넌트 UI를 그린 후 테스트를 진행하는 것이고, e2e 테스트는 사용자가 실제 사용하는 것 처럼 페이지 URL에 접근하여 테스트를 진행하는 것이다.

 

사실 두 테스트는 코드를 통해 컴포넌트 UI를 그림 or 페이지에 실제로 접근, 이렇게 조건에 차이만 있기 때문에 강의에서는 두 테스트를 구분하는 것은 무의미할 수 있다고 말하고 있다.

 

Jest vs Cypress vs Vitest

 

여러가지 테스트 도구들이 있지만 그들 중에서 위 세가지가 가장 유명하고 널리 쓰이는 도구들이다.

 

강의에서는 Cypress를 추천하고 있다.

Vitest는 아직 인사이트가 많지 않고, Jest는 적절한 사용을 위해 세팅해야할 것이 너무 많아 오버 엔지니어링이 될 수 있다고 말하고 있다.

 

참고 자료

 

https://www.inflearn.com/course/%EC%A3%BC%EB%8B%88%EC%96%B4-%ED%94%84%EB%A1%A0%ED%8A%B8%EC%97%94%EB%93%9C-%ED%85%8C%EC%8A%A4%ED%8A%B8-%EA%B8%B0%EB%B3%B8%EA%B8%B0#curriculum

2시간으로 끝내는 프론트엔드 테스트 기본기 | 강병진 - 인프런