Clean Code

Chapter 9 : 단위 테스트

9.1 TDD 법칙 세 가지

첫 번째 법칙 : 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.

두 번째 법칙 : 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.

세 번째 법칙 : 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.

세 가지 규칙을 따를 경우 이익

개발과 테스트가 30초 주기로 묶임

매일 수십 개, 매달 수백 개, 매년 수천 개의 테스트 코드가 나옴

방대한 테스트 코드는 심각한 관리 문제를 유발함

9.2 클린 테스트 코드 유지하기

테스트 코드가 클린 하지 못한다면?

실제 코드를 짜는 시간 < 테스트 코드를 짜는 시간

실제 코드를 변경 기존 테스트 케이스 실패 테스트 코드가 부담이 됨

새 버전을 출시할 때 마다 테스트 케이스 유지보수 비용 증가

테스트 코드 폐기 프로젝트 결함률 증가

테스트 코드를 깨끗이 유지해야 한다!!!

9.3 클린 테스트 코드

클린 테스트 코드를 작성시 가장 중요한 것은?

가독성!!!!!!

가독성이 안 좋은 코드 예

PathParser 객체 :

테스트 코드와 무관 테스트 코드의 의도를 흐림

Responder 객체 생성, response 수집 및 변환 코드 :

테스트 코드와 무관 테스트 코드의 의도를 흐림

예제 코드 [목록 9-2]

리펙토링 코드

의미를명확하게해줌!

Build-Operate-Check 패턴이 위와 같은 구조에 적합!

Build Operate Check 패턴

이중 표준

테스트 코드는 클린코드여야 하지만 효율적일 필요는 없다.

실제 환경과 테스트 환경은 요구사항이 다르기 때문에 각각의 환경에맞는 코드를 작성하면 된다.

예제 코드 [목록 9-3]

점검 상태이름 과 상태 값 확인을확인하는게 번거로움

tic() 함수가 뭐하는 거지?

대문자 : 켜짐소문자 : 꺼짐

문자 : { heater, blower, cooler, hi-temp-alarm, lo-temp-alarm }

tic() 함수를 숨김

리펙토링 코드

임베디드 시스템 상에선 자원이 제한적일 수 있기 때문에StringBuffer를 사용하는게 효율적이다.

하지만 테스트 환경에선 그럴 필요가 없다. (이중 표준)

리펙토링 코드

참고 : StringBuffer 사용법

일단 모양은 지저분 하네요…

성능은 어떨까요?

출처 : http://javacan.tistory.com/entry/39

참고 : StringBuffer vs String 성능 비교

9.4 테스트 당 assert 하나

Test case 1: 출력이 XML 이다

Test case 2: 특정문자열을 포함한다.

출처 : http://martinfowler.com/bliki/GivenWhenThen.html

코드 중복 발생

해결책 : 템플릿 메소드 패턴 등등등…. assert 문을 여럿 사용하는 편이 낫다!!!

테스트 당 개념 하나

한 테스트에 여러 개의 개념을 넣게 되면 각 절이 거기에 존재하는

이유와 각 절이 테스트 하는 개념을 모두 이해해야 한다.

한 테스트에 3개의 개념이 들어있는 코드

9.5 F.I.R.S.T

FAST(빠르게)

테스트는 빨라야 한다.

테스트가 느리면 자주 돌릴 엄두를 못 낸다. 자주 돌리지 못하면 초반에 문제를 찾아내고치지 못한다. 코드를 맘껏 정리하지도 못한다. 결국 코드 품질이 망가지기 시작한다.

INDEPENDENT(독립적으로)

각 테스트는 서로 의존하면 안 된다.

한 테스트가 다음 테스트가 실행 될 환경을 준비해선 안 된다. 각 테스트는 독립적으로그리고 어떤 순서로 실행해도 괜찮아야 한다. 테스트가 서로에게 의존하면 하나가 실패할 때 나머지도 잇달아 실패하므로 원인을 진단하기 어려워 지며 후반 테스트가 찾아내야 할 결함이 숨어진다.

REPEATABLE(반복 가능하게)

테스트는 어떤 환경에서도 반복이 가능해야 한다.

실제환경, QA 환경, 버스를 타고 집으로 가는 길에 사용하는 노트북환경에서도 실행할수 있어야 한다. 테스트가 돌아가지 않는 환경이 하나라도 있다면 테스트가 실패한 이유를 둘러댈 변명이 생긴다.

SELF-VALIDATING(자가 검증하는)

테스트는 Bool 값으로 결과를 내야 한다.

성공 아니면 실패다. 통과 여부를 알려고 로그 파일을 읽게 만들어서는 안 된다. 통과 여부를 보려고 텍스트 파일 두 개를 수작업으로 비교하게 만들어서도 안 된다. 테스트가스스로 성공과 실패를 가늠하지 않는다면 판단은 주관적이 되어 버리며 지루한 수작업평가가 필요하게 되어 버린다.

TIMELY(적시에)

테스트는 적시에 작성해야 한다.

단위 테스트는 테스트하려는 실제 코드를 구현하기 직전에 구현한다. 실제 코드를 구현한 다음에 테스트 코드를 만들면 실제 코드가 테스트 하기 어렵다는 사실을 발견할지도모른다. 어떤 실제 코드는 테스트하기 너무 어렵다고 판명 날지 모른다. 테스트가 불가능하도록 실제 코드를 설계할지도 모른다.

9.5 결론

테스트 코드를 지속적으로 깨끗하게 관리하자.

End