[TDD] 테스트 코드 작성 순서

테스트 코드 작성 순서

- 쉬운 경우에서 어려운 경우로 진행

- 예외적인 경우에서 정상인 경우로 진행

 

초반에 복잡한 테스트부터 시작하면 안되는 이유

 -> 초반부터 다양한 조합을 검사하는 상황을 테스트로 추가하면 해당 테스트를 통과시키기 위해 한 번에 구현해야 할 코드가 많아진다.

 

구현하기 쉬운 테스트부터 시작하기

 -> 가장 구현하기 쉬운 경우부터 시작하면 빠르게 테스트를 통과시킬 수 있다.
  ex) 모든 조건을 충족 하는 경우 > 한 규칙만 충족하는 경우 > 모든 조건을 충족하지 않는 경우

 

예외 상황을 먼저 테스트해야 하는 이유

  -> 초반에 예외 상황을 테스트하면, 예외 상황에 따른 if-else 구조가 미리 만들어지기 때문에 많은 코드를 완성한 뒤에 예외 상황을 반영할 때보다 코드 구조가 덜 바뀐다.

 

완급 조절 - 한 번에 얼마만큼의 코드를 작성할 것인지 아래 단계에 따라 TDD를 익혀보기

  1. 정해진 값을 리턴

  2. 값 비교를 이용해서 정해진 값을 리턴

  3. 다양한 테스트를 추가하면서 구현을 일반화

 

지속적인 리팩토링

  -> 테스트를 통과한 뒤에는 리팩토링을 진행한다. 코드 중복은 대표적인 리팩토링 대상이다.

TDD를 진행하는 과정에서 지속적으로 리팩토링을 진행하면 코드 가독성이 높아진다.

코드 가독성이 높아지면 개발자는 더욱 빠르게 코드를 분석할 수 있어 수정 요청이 있을 때 변경할 코드를 빠르게 찾을 수 있다.

코드 변경의 어려움을 줄여주어 향후 유지보수에 도움이 된다.

 

상수 -> 변수 변경, 변수 이름 변경 등 작은 리팩토링은 발견하면 바로 실행하고,

메서드 추출과 같이 메서드의 구조에 영향을 주는 리팩토링은 큰 틀에서 구현 흐름이 눈에 들어오기 시작한 뒤에 진행한다.

 

파라미터 개수는 적을수록 코드 가독성과 유지보수에 유리하므로 메서드의 파라미터 개수가 세 개 이상이면 객체로 바꿔 한개로 줄이는 것을 고려해야 한다.