- 아주 예전 개발자들은 실제 코드가 돌아간다는 사실을 확인하고 테스트 코드를 버렸다.
- 하지만 지금 같은 경우엔 코드가 제대로 도는지 황긴하는 테스트 코드를 수 없이 작성하고, 모든 테스트 케이스를 통과한 후엔 실제 제품 코드와 같은 소스 패키지로 확실하게 묶는다.
- 하지만 많은 프로그래머들이 제대로 된 테스트 케이스를 작성해야 한다는 좀 더 미묘한 (그리고 더욱 중요한) 사실을 놓쳐버렸다.
TDD 세 가지 법칙
- TDD 는 실제 코드를 짜기 전에 단위 테스트부터 짜라고 요구한다.
- 이 외에 다음 세 가지 법칙을 살펴보자.
- 1)첫번째 법칙: 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.
- 2)둘째 법칙: 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.
- 3)셋째 법칙: 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.
- 위 세 가지 규칙을 따르면 개발과 테스트가 대략 30초 주기로 묶인다.
- 테스트 코드와 실제 코드가 함께 나올뿐더러 테스트 코드가 실제 코드보다 불과 몇 초 전에 나온다.
- 이렇게 일하면 매일 수십개, 매달 수백개, 매년 수천 개에 달하는 테스트 케이스가 나온다.
- 이렇게 이랗면 실제 코드를 사실상 전부 테스트하는 테슽트 케이스가 나온다.
- 하지만 실제 코드와 맞먹을 정도로 방대한 테스트 코드는 심각한 관리 문제를 유발하기도 한다…
✨깨끗한 테스트 코드 유지하기✨
- 지저분한 테스트 코드를 내놓는 것은 테스트를 안 하는 것보다 더 못하다.
- 문제는 실제 코드가 진화하면 테스트 코드도 변해야 한다는데 있다.
- 그런데 테스트 코드가 지저분할수록 변경이 어려워진다.
- 테스트 코드가 복잡할수록 실제 코드를 짜는 시간보다 테스트 케이스를 추가하는 시간이 더 걸리기 십상이다.
- 실제 코드를 변경해 기존 테스트 케이스가 실패하기 시작하면, 지저분한 코드로 인해, 실패하는 테스트 케이스를 점점 더 통과하기 어려워진다.
- 그래서 테스트 코드는 계속해서 늘어나는 부담이 된다..
- 그렇다고 테스트 슈트가 없으면 개발자는 자신이 수정한 코드가 제대로 도는지 확인할 방법이 없다.
- 시스템 이쪽을 수정해도 저쪽이 안전하다는 사실을 검증하지 못한다.
- 그래서 시스템이 커질수록 결함율이 높아지기 시작하고 의도하지 않은 결함 수가 많아지면 개발자는 변경을 주저하게 된다.
- 변경하면 득보다 해가 더 크다 생각해 더 이상 코드를 정리하지 않게 되고 코드가 망가지기 시작한다..
- 결국 테스트 슈트도 없고, 얼기설기 뒤섞인 코드에, 좌절한 고객과 테스트에 쏟아 부은 노력이 허사였다는 실망감만 남게 된다….
- 이러한 현상의 근본적인 원인은 테스트 코드를 막 짜도 좋다고 허용한 결정 및 마인드다.
- 필자가 위와 같이 얘기하는 이유는 필자가 참여하고 조언한 많은 팀이
깨끗한단위 테스트 코드로 성공했기 때문이다. - 테스트 코드는 실제 코드 못지 않게 중요하고 깨끗하게 짜야한다.
- 이류 시민이 아니다.
- 사고와 설계와 주의가 필요하다.
- 필자가 위와 같이 얘기하는 이유는 필자가 참여하고 조언한 많은 팀이
Reference
- 예제 코드 및 이미지 출처