(블챌용) 테스트 코드

1.1 테스트 코드 작성의 목적과 장점

1.1.1 테스트코다 작성의 목적

• 정확성 및 신뢰성 확보:
  • 테스팅의 주요 목적은 코드가 올바르게 작동하는지 확인하는 것
  • 다양한 조건 및 입력에서 React 컴포넌트와 코드가 예상대로 작동하는지 확인
• 수월한 리팩토링:
  • 프로젝트가 성장하면 리팩토링이 필요함
    • 코드 품질, 성능 개선 또는 새로운 패턴 적용 등
  • 리팩토링 전 테스트코드를 작성하면 최소한의 기준이 만들어짐
  • 변경사항 또는 최적화가 예상치 못한 버그를 초래하지 않도록
  • 개인적으로는 리팩토링 전에 테스트코드 작성하는 것을 추천
    • 프로젝트 초반부터 테스트코드를 작성하면서 진행하면 좋지만 일반적으로 시간이 부족함
    • 추후 개선할 때 테스트코드 작성으로 안전망을 둘러두고, 리팩토링 진행하는 것을 추천

1.1.2 테스트코드 작성의 장점

• 문서화 및 이해:
  • 명확하게 작성된 테스트는 문서의 형태
    • 내가 작성한 코드가 기획의도를 확실히 반영하는지
    • 기획 내용을 꼼꼼하게 반영했는지
    • 기획자와의 소통의 도구로도 사용할 수 있음

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

    다른 개발자들은 테스트를 보고 컴포넌트나 함수의 예상되는 동작을 이해할 수 있음코드 파악이 용이함
  • 새로운 개발자가 조인했을 때 온보딩이 수월해짐

1.2 무엇을 테스트 할 것인가?

• 테스트의 목적에 대해
  • 코드가 올바르게 동작하는지 확인하는 것
  • 이벤트를 테스트 한다
  • 브라우저에서 내가 작성한 코드가 잘 동작하는지 확인하기 위함
• 테스트 해야할 항목들
  • 코드가 올바르게 동작한다는 것은?
    • 사용자가 서비스를 사용하는데 문제가 없다는 것
  • 그렇다면 우리는 비지니스 로직을 테스트 해야한다
    • 코드가 잘 “동작” 하는지를 확인하기 위한 테스트
    • 버튼을 클릭했을 때 내가 의도한대로 잘 동작하는지?
      • 로그인 성공 시 내가 원하는 화면으로 잘 redirect 되는지
      • 로그인 실패 시 내가 원하는 에러메시지가 잘 나오는지
      • 인풋이 잘 입력되는지
      • 버튼이 잘 클릭되는지
      • 로그인 성공, 실패가 확인되는지
      • 로그인 버튼에서 텍스트의 위치
        • 디자인 가이드를 준수해야 프로젝트 완성도가 상승함
• 테스트 하지 않아도 되는 것들
  • UI 테스트
    • 로그인을 테스트 할 때, 인풋과 버튼의 존재를 확인하긴 해야함
    • 하지만 아이디, 비밀번호 인풋간의 마진이나 버튼의 패딩 등은 테스트 하지 않아도 됨
      • 어차피 우리는 반응형을 고려해야 함

1.3 다양한 유형의 테스트

• 유닛테스트
  • 가장 작은 단위의 테스트
  • 로그인을 예로 들면
    • 위에서 언급한 인풋이나 버튼들이 잘 렌더링 되는지
    • 이메일 인풋의 값이 잘 변경되는지
    • 버튼을 클릭하면 로그인이 잘 되는지
  • 회원가입을 한다면 비밀번호가 설정한 규칙에 잘 맞는지?
• 통합테스트
  • 다양한 컴포넌트 / 모듈 / 함수들이 잘 연결되는지 확인함
    • 즉, 유닛테스트의 결과물들이 하나로 묶여서 잘 작동하는지
  • 로그인을 예로들면…
    • 로그인 버튼을 클릭하고, 로그인 성공 시 원하는 화면으로 잘 redirect되는지
    • 로그인 실패하면 별도로 선언한 Modal이 잘 보여지는지
    • 가입된 이메일과 비밀번호를 사용해서 로그인이 잘 되는지
    • 잘못된 정보로 로그인 시도할 경우 에러메세지가 잘 나오는지
    ⇒ Input과 버튼이 서로 상호작용을 잘해서 결과물이 나오는지 확인하는것!!
• E2E테스트
  • 실제 사용자인것처럼 테스트
  • 유닛테스트 + 통합테스트
  • 개발 비용이 가장 비싸다고 보면될듯
• e2e vs 통합 테스트
  • 컴포넌트를 렌더링하고 테스트를 하냐? ⇒ 통합 테스트
  • 페이지에 접근해서 테스트를 하냐? ⇒ e2e
• 프론트엔드는 이 경계가 모호한 것 같다
  • 일반적인 통념은
    • 유닛테스트, 통합테스트는 jest를 활용하고
    • e2e 테스트는 cypress를 활용
  • 그런데, cypress로 유닛테스트나 통합테스트도 충분히 가능
    • 굳이 우리는 유닛테스트만 한다, 우리는 e2e테스트까지 한다 보다는 우리는 테스트코드를 작성한다 가 더 좋은 개념이라고 생각함