Chapter04. TDD - TDD 사전 준비, 구현 시 유의할 점

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

 

기능은 입력과 결과로 이루어져있음
 -> 로그인 기능
     입력 : 아이디, 비밀번호
     결과 : 아이디와 비밀번호가 일치하는 계정이 존재한다면 성공, 일치하는 계정이 없다면 실패

  -> 결과의 형태는 다양함
      1차적인 형태는 성공, 실패
      2차적인 형태는 결괏값을 반환, 예외를 발생, 결과 없음

      결과 없음 : 파일 저장, 수정, 삭제 등 / DB에 데이터 저장, 수정 삭제 등과 같은 시스템 변경
                    DB에 데이터 저장, 수정, 삭제 후 영향 받은 행의 수로 결과(성공/실패)를 판단할 수 있지만 정확한 판단은 아님
                    코드 작성 중 실수로 오타가 들어가 데이터를 저장하긴 했지만 입력 받은 데이터가 아닌 엉뚱한 데이터가 들어갈 수도 있음
                    결과가 없을 때 결과를 확인하기 위해서는 입력 값으로 조회하는 등의 방법을 사용해야함

      한 기능의 결과는 다양한 형태의 결과들로 이루어질 수 있음
      회원 가입 시 이미 사용중인 아이디일 경우(예외 발생/실패), 사용하고 있지 않는 아이디일 경우(회원 번호 반환/성공)

테스트 케이스는 테스트할 기능, 결과 검증으로 이루어져있음
 -> 테스트할 기능 : 메서드
 -> 결과 검증 : assert 로 시작하는 메서드

 구현 시 각 테스트 케이스를 통과할 만큼만 구현해야함, 필요할 것 같다고 미리 구현하면 안됨
 설계를 떠올리면 됨, 모든걸 다 갖춘 완벽한 설계를 하면 좋겠지만 그러한 설계는 존재할 수 없고 설계를 복잡하게 만듬
 개발이나 서비스를 하면서 고객이 필요한 만큼 설계가 추가되 점점 복잡해지듯이 구현도 해당 테스트 케이스를 통과할 만큼만 구현해야하고 테스트 케이스가 추가되면서 점점 구현이 명확해지고 복잡해져야함
 -> 로그인 기능 테스트
    1. 아이디, 비밀번호를 올바르게 입력한 경우(테스트 케이스1) : 로그인 성공을 결과로 반환함, 이때 아이디, 비밀번호를 입력하지 않은 경우 또는 아이디, 비밀번호를 잘못 입력한 경우와 같은 것도 고려해 로그인 기능에 미리 코드를 추가할 수 있으나 현재 테스트 케이스에 포함되는 내용이 아니므로 절대 추가하면 안됨
    2. 아이디, 비밀번호를 잘못 입력한 경우(테스트 케이스2)
    3. 아이디, 비밀번호를 입력하지 않은 경우(테스트 케이스3)
    ...

테스트 케이스를 나열하기 전 요구사항 명세서를 보고 기능 명세를 구체화하자
 요구사항 명세서(스토리보드, 와이어프레임 등)는 개발자가 보기에 생략된 내용들이 있을 수 있으므로 요구사항 명세서를 보고 바로 테스트 케이스를 나열하지 말고 우선 기능 명세를 구체화해야함
 위에서 언급한대로 기능은 입력과 결과로 이루어져있는데 입력과 결과 둘 중 어느 하나라도 명확하지 않으면 기능을 개발할 수 없음
 예를 들어 요구사항 명세서에는 한달 이라고 명시 되어있지만 한달의 기준은 사람마다 또는 시스템 마다 다를 수 있음
 4월 1일을 기준으로 한달 뒤일 때 월을 기준으로 본다면 5월 1일이 될 수 있음 또한 일을 기준으로 본다면 한달은 30일이라고 생각했을 때 4월 1일을 포함하느냐 하지 않느냐에 따라 4월 30일이 될 수 있음
 또한 1월 31일을 기준으로 한달 뒤라면
 1. 1월 말일이므로 한달뒤는 다음달의 말일이다 라고 생각했을 경우 2월 28일
 2. 한달은 30일이다, 오늘을 포함한 한달 뒤를 생각했을 경우 3월 1일
 3. 한달은 30일이다, 오늘을 포함하지 않는 한달 뒤를 생각했을 경우 3월 2일