테스트란?

• 애플리케이션의 품질과 안정성을 높이기 위해서, 사전에 결함을 찾아내고 수정하기 위한 행위

<aside> ✅ 특정 모듈(컴포넌트)이 사양에 잘 동작하는지 자동화된 테스트로 검증

</aside>

⇒ 개발 비용 증가함.

테스트 코드의 효과 (얻을 수 있는 장점)

1. 좋은 설계에 대한 사고를 도와준다.

   • 컴포넌트 단위가 크고 강하게 결합되어 있다면, 검증해야할 범위가 커진다.

   • 결합도 : 어떤 모듈이 다른 모듈에 의존하는 정도

     

   • 결합도가 높아져 버리면, 특정 기능만 따로 검증하기 어려움.

   • 복잡한 구조로 필요한 테스크가 누락될 수 있음

   • 결합도가 높기 때문에 여러 테스트 코드를 수정해야함.

   • 테스트 단위를 어떻게 나눌지 생각하다 보면, 어떤 상태를 어느 컴포넌트에서 관리할지 어떤 컴포넌트에서 api를 호출할지 올바른 설계에 대해 고민하게 된다.

2. 테스트 코드를 기반으로 빠르고 안정적으게 리팩토링을 할 수 있다.

   • 리팩토링 : 결과의 변경없이 코드의 구조를 재정의함.

     

     

   1. 좋은 테스트 코드는 애플리케이션의 이해를 돕는 문서가 된다.
      • 테스트 코드만 보더라도, 현재 페이지가 어떻게 흘러가는지 파악할 수 있는 문서가 된다.

올바른 테스트 작성을 위한 규칙은 뭐가 있을까?

인터페이스를 기준으로 테스트 작성하자!!

• 실제 setState로 상태 변경을 하지말고, 테스팅 라이브러리들의 인터페이스를 이용하자 Why?
  • 실제 코드들과 종속성이 없고, 캡슐화에 위반되지 않음.
  • 라이브러리들의 인터페이스만 보더라도 어떤 행위를 하는지가 명확해진다.
  • 테스트를 설명하기 위한 불필요한 주석이나 설명 또한 필요 없다.

커버리지 보다는 ⭐️의미있는 테스트 인지⭐️ 고민하자.

export const isNumber = (value) => typeof value === 'number';
export const isString = (value) => typeof value === 'string';

• 위 코드는 테스트 코드가 필요할까?

  • 이런 간단한 로직은 테스트를 건너뛰어도 된다.

  <aside> ✅ 커버지리지만을 위한 검증은 의미없는 테스트가 될 가능성이 높다.

  </aside>

  

<aside> 💁🏼 100% 커버리지를 목표로 테스트 코드를 작성하면, 오히려 불필요한 리소스가 드는 것 일 수도 있다.

</aside>

<aside> 💁🏼 의미 없는 테스트 (예를들어 단순 렌더링)은 비용 낭비임.

</aside>