링크
제공 : 인프런
강의자 : 코드조커, 오프

'테스트'를 왜 해야하는가?

테스트 : 사전에 결함을 찾아내고 수정하기 위한 행위.
개발비용은 증가하지만 유지 보수 비용이 크게 줄어든다는 장점.

이게 가장 큰 목적이지만 그 외에도 부가적인 효과를 가져온다.

1. 좋은 설계에 대한 사고를 가지도록 한다.

거대한 모듈, 혹은 모듈간의 결합도가 높은 설계는 테스트하기 불편하고 그래서 좋지 않은 코드다. 테스트 코드를 작성하면 자연스럽게 모듈간의 분리가 생긴다.

• 복잡한 구조의 문제 : 가독성 하락으로 테스트 누락. 높은 결합도로 테스트 코드를 계속 수정해야 함.
• 페이지 단위의 테스트는 사실상 불가능.

2. 빠르고 안정적인 리팩토링

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

리팩토링 후에 진행한 테스트 결과가 전의 결과와 일치한다는 것은 리팩토링이 성공적으로 완료되었다는 것인데, 이 여부를 빠르게 확인할 수 있다. 그래서 큰 규모의 리팩토링을 할때 단계별로 빠르고 안정적이게 진행할 수 있다.

• 리팩토링의 핵심은 소규모 변경과 변경마다 진행하는 테스트. 한 가지를 수정할 때마다 테스트를 진행해, 오류가 생기더라도 변경 폭이 작기 때문에 살펴볼 범위도 좁아서 문제를 찾고 해결하기가 훨씬 용이.

3. 애플리케이션의 이해를 돕는 '문서'가 되기도 한다.

실무에서도 개발문서를 보아도 이해하지 못하는 경우가 잦은데, 테스트 코드는 개발자의 의도를 이해하는데 도움이 된다.

테스트 작성을 위한 규칙

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

인터페이스 : 서로 다른 클래스 또는 모듈이 상호작용하는 시스템

클래스(모듈) 내부 세부 구현을 테스트하는것이 아니라 외부에 노출되는 public 메소드 기준으로 작성해야 한다.

• 예) setState대신 dom이벤트핸들러로 컴포넌트 안에서 상태를 변경하도록 하는것이 좋은 테스트 코드.

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

커버리지 : 구문, 분기 Branches, 함수, 줄을 기준으로 테스트 코드가 전체 코드의 얼마나 검증하고 있는지 나타내는 지표.

100% 커버리지가 도달 가능한 목표인가?
단순해서 테스트가 필요없는 코드가 있다. (검증할 가치가 있는 로직 or 상태변경이 부재)

3. 테스트 코드도 유지 보수의 대상.

가독성을 높이기 위해 테스트 내용 명확히 기재.

하나의 테스트에서 (가급적) 하나의 동작만 검증.

• 단일 책임의 원칙(SRP) : 모든 클래스는 하나의 책임을 갖고 관련된 책임을 캡슐화하여야 한다.
• "장바구니에 담긴 상품들이 정상적으로 노출되고, 수량을 변경하면 가격이 제계산된다. 그리고 삭제 버튼을 누르면 상품이 삭제된다" 여기에는 3개의 책임.
  • 여기서 가격수정 로직이 변경되면 테스트 코드 전체를 수정해야한다.