< 내용은 다시 공부할 때 개선할 예정 >

 

TDD 과정
  1. 만들 기능 정의
  2. 만들 기능명 정의
  3. 빈 테스트 메서드를 하나 만들고 실행
    메서드가 하나의 테스트 단위이므로 sample, test 등의 이름으로 빈 테스트 메서드를 하나 만들고 실행
    테스트 하기 위한 최소한의 준비가 됐는지 확인하는 절차 ( 돌다리도 두들겨보고 건너라 )

    테스트 메서드명은 한글로해도 됨
    이유 : 테스트 메서드이므로 / 단, 실제 개발 메서드는 한글로 하면 안됨
  4. 테스트하며 기능 개발
    4-1. 첫 번째 테스트는 굉장히 중요함 / 첫 단추를 제대로 잠궈야하듯이
          첫 번째 테스트로는 가장 쉽거나 가장 예외적인 상황으로 진행

          가장 쉬운 상황 - 필요한 값을 전달하는 상황
          가장 예외적인 상황 - 아무 값도 전달하지 않는 상황

          가장 예외적인 상황을 첫 번째 테스트로 하면 테스트 코드 작성 후 테스트하기까지 시간이 굉장히 오래 걸림
          이유 : 아무 값도 전달하지 않으므로 "필요한 값이 없을 때 어떻게 해라" 라는 예외 처리를 전부 하고 난 뒤에 테스트를 할 수 있으므로

          가장 쉬운 상황을 첫 번째 테스트로 하면 테스트 코드 작성 후 테스트하기까지 시간이 비교적 짧게 걸림
          이유 : 필요한 값을 전달하므로 전달 받은 값으로 원하는 결과가 출력되는지 바로 테스트 해볼 수 있으므로

          따라서 첫 번째 테스트로는 가장 쉬운 상황을 선택하는게 일반적임

          첫 번째 테스트를 위한 메서드 선언
          테스트 마다 테스트만 통과 시키기 위한 최소한의 코드를 작성하는 것이 원칙

          필요한 클래스, 메서드 등이 이미 다 준비되어있다고 가정하고 테스트 코드 작성 후 테스트
          당연히 클래스, 메서드 등이 없다며 예외가 발생함
          클래스를 가장 최소한으로만 구현, 메서드 또한 가장 최소한으로만 구현함
          최소한으로만 구현한다 -> 테스트 값이 원하는 결과를 직접 만들어내도록 구현 / 조건문, 반복문 등 로직이 전혀 들어가지 않은 상태

          두, 세개정도 값으로 클래스, 메서드를 더 호출해 원하는 결과가 나오는지 테스트를 한 후 첫 번째 테스트 끝냄
    4-2. 첫 번째 상황과는 다른 상황을 하나씩 점진적으로 테스트
          다른 상황을 테스트할 테스트 메서드 작성 후 실행
          당연히 테스트에 실패함 / 이제 4-1, 4-2 모두 통과할 수 있도록 코드 수정
  5. 테스트 코드도 코드이므로 리펙토링 및 유지보수를 해야함

구현 과정 : 테스트 -> 통과  -> 리펙토링

TDD의 큰 장점 : 누구나 해당 코드를 리펙토링 할 수 있게 해준다.
  리펙토링을 할 때 가장 꺼려지는 부분이 "원래 잘 작동하고 있는 코드인데 괜히 내가 손대서 문제가 생기는거 아닐까?"
  TDD로 개발을 하면 리펙토링을 했을 때 문제 없이 동작하는지 체크 해줄 수 있는 테스트 케이스들이 이미 완성 되어있음
  리펙토링할 코드가 프로세스 내 에서 어떤 역할을 하는지 몰라도 됨 / 리펙토링에만 집중할 수 있음

728x90
LIST