9장. 단위테스트

실제 코드를 치기 전부터 테스트 코드를 치라구?

대체 왜?

 

Why

우리는 왜 테스트 코드를 작성해야 할까? 근본적인 이유에 대해 생각해 볼 필요가 있을 것이다.

그 이유는 '검증이 된 코드인가?'에 대한 명확한 답을 제시할 수 있기 때문이다.

테스트 코드가 없으면, 우리는 이 코드가 제대로 돌아가는 지 검증할 수 있는 방법이 없다. 시스템의 주요한 부분을 수정했을 때, 이 수정한 부분이 다른 소스에 영향이 있는지 없는지를 판단할 기준이 없는 것이다.

이는 결함률을 높이는 원인이 된다. 그래서 테스트 주도 개발(TDD) 개념이 오늘날 성립된 것이다.

(많은 선배들의 경험 끝에...)

 

TDD란

: Test Driven Development(테스트 주도 개발)의 약자로,

매우 짧은 개발 사이클을 반복하는 소프트웨어 개발 프로세스 중 하나이다. 개발자는 먼저 요구사항을 검증하는 자동화된 테스트 케이스를 작성한다. 그런 후에, 그 테스트 케이스를 통과하기 위한 최소한의 코드를 생성한다. 마지막으로 작성한 코드를 표준에 맞도록 리팩토링한다. 이 기법을 개발했거나 '재발견' 한 것으로 인정되는 Kent Beck은 2003년에 TDD가 단순한 설계를 장려하고 자신감을 불어넣어준다고 말하였다. (by 위키백과)

 

TDD 법칙 세 가지

1. 실패하는 단위 테스트를 작성할 때 까지 실제 코드를 작성하지 않는다.

2. 컴파일은 실패하지 않으면서, 실행이 실패하는 정도로만 단위테스트를 작성한다.

3. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.

 

실제코드아 테스트 코드가 함께 나오기 때문에, 실제코드를 사실상 전부 테스트 할 수 있다고 이야기 할 수 있겠다.

실제코드와 테스트 코드 사이의 간격이 크다면, 분명 한계점에 봉착하게 된다.

실제 코드가 변형되면 테스트 코드도 변형되어야 하는데, 실제 코드가 복잡하고 지저분한 코드들로 가득차 있으면 당연히 테스트 코드를 짜기 어려워진다. 이러한 관습이 반복되면, 어느 새 우리는 테스트 코드를 놓아버리게 될 것이고.

 

깨끗한 테스트 코드

테스트 코드는 실제 코드 못지 않게 중요하다!

테스트는 유연성, 유지보수성, 재사용성을 제공한다.

👉이를 위한 것이 바로 단위 테스트(Unit Test) 이다.

테스트 케이스가 없다면 모두 잠정적인 버그다!🐞

(이 말이 무섭다...)

 

단위테스트는 실제 코드를 점검하는 자동화된 단위의 테스트로, 설계와 아키텍쳐를 최대한 깨끗하게 보존하게 해준다.

 

깨끗한 테스트는 다음의 다섯가지 규칙을 따른다.

F.I.R.S.T

Fast : 빠르게

테스트 코드는 런타임이 빨라야 한다. 테스트가 느리면, 프로젝트 초기 단계에 일정 차질의 주요 원인이 된다.

Independent : 독립적으로

테스트는 서로 의존적이게 작성해서는 안된다.

각 테스트가 실행 순서에 영향을 받지 않고, 언제 수행되든 통과하도록 만들어야 연쇄 실패를 방지할 수 있다.

Repeatable : 반복 가능하게

어느 환경(개발, QC, 운영)에서도 테스트 수행이 가능해야 한다.

Self-Validatign : 자가검증하는

작업자가 로그 파일을 까러가는 순간까지 가만두지 않아야 한다.

성공 아니면 실패로 결과를 낸다.

Timely : 적시에

단위 테스트는 테스트하려는 실제 코드를 구현하기 직전에 작성해야 한다.

실제 코드를 구현한 다음에 만들면, 실제 코드가 테스트 하기 너무 어려울 수도 있을 것이다.

혹은 최악의 경우 테스트가 불가능하도록 설계되었을 지도 모른다.