[Daily Contents] 테스트주도개발 TDD

코딩은 결정, 피드백의 연속

이 함수는 이런 기능을 짜야겠군 -> 결정(Decision)
그런데 내가 이 함수를 잘 만든 걸까? -> 피드백(Feedback)
그럼 함수를 완성하고 여기에 피드백을 받을 테스트 케이스를 만들어야겠다!

코드 -> 테스트케이스

• 현재 시간이 AM, PM인지 판단하여 리턴하는 함수

public string GetAMorPM() {
  var now = DateTime.Now;
  if(now.Hour < 12) {
    return "AM";
  } else {
    return "PM";
  }
}

• 문제점은? 테스트를 하려면 오전, 오후가 될 때까지 기다려야 하나?
• 코드부터 작성하면 테스트 코드를 작성하기가 쉽지 않다!

테스트를 어렵게 만드는 것은…?

불확실성 : 임의의 값, 임의의 시간 필요

• 전역변수, 외부 API서버로부터 받는 값 등

부수작업들…

• DB에 기록
• 메일 발송

• 외부에 뭔가를 전달하지만 리턴값이 없는…

• 결정과 피드백 사이의 간격이 커져버린다.(코드 작성 싱에는 왜 몰랐을까?) 좁히려면 너무 많은 비용이 든다. - Kent Back

테스트케이스 -> 코드

테스트케이스

assertThat(getAMorPM(10:00), equalTo("AM"));
assertThat(getAMorPM(14:00), equalTo("PM"));

코드 - 여기에 맞춰 코드를 작성하면 외부 라이브러리 Datetime는 개입이 되지 않는다.

public string GetAMorPM(time) {
  if(time.Hour < 12) {
    return "AM";
  } else {
    return "AM";
  }
}

• TDD는 단위 테스트다? 테스트를 많이 해 보는 것이다? (X)
• TDD는 테스트부터 짜고 코드를 작성하는 것 (O)

실습: 로그인 기능 개발

• 로그인 기능에 몇 개의, 어떤 케이스가 필요할까?

NO	When	Given	Then
1	로그인 버튼 클릭	ID: 정상 + PW: 일치	정상 로그인
2	로그인 버튼 클릭	ID 미입력	ID 입력 메세지 팝업
3	로그인 버튼 클릭	PW 미입력	PW 입력 메세지 팝업
4	로그인 버튼 클릭	ID 입력 + PW: 불일치	PW 확인 요청 메세지
5	로그인 버튼 클릭	ID: 없는 ID 입력 + PW: 아무 값	없는 ID 메세지 팝업

파일 : 별도 제공

정리

• TDD는 원하는 코드를 먼저 하는 게 아니라 테스트 케이스를 먼저 만들고 이를 만족시켜 가며 목적 함수를 만든다.
• 테스트부터 짜면 다음과 같은 이점이 있음
  • 테스트 수행 커버리지를 100%로 맞추기 쉽다.
  • 테스트 가능한 코드가 저절로 만들어진다. -> Clean Code의 기초
• 수행 케이스는 “함수” 관점에서… 관통 케이스를 TDD로 하기는 어렵다.

그럼 단점은?

• 테스트에 걸리는 시간만큼 개발 시간이 필요하다.
• 진입장벽이 있어 습관화하기 어렵다.
• 생각지 못한 테스트의 경우수가 있을 수 있다.