[Clean Code] #9 단위 테스트

TDD 법칙 세 가지

1. 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.
2. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.
3. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.

 

테스트 코드는 실제 구현 코드와 함께 수많은 코드라인이 생성되게 되고, 테스트 코드 관리 부분에 대한 문제를 유발한다.

 

 

깨끗한 테스트 코드 유지하기

 

단순 현재 테스트 과정만을 넘어가기 위해서 아무렇게나 테스트 케이스를 작성하는 것은 문제가 되지 않는다.

하지만 이후 변경사항을 적용하고, 유지 보수 부분에서 이전에 마구 짰던 테스트 케이스는 그 테스트 코드를 유지 보수하는 비용 또한 증가하기 때문에 비효율적으로 작용하게 된다.

 

테스트 코드도 실제 코드만큼이나 중요하다.

 

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

테스트 코드를 잘 짜 놓으면 변경사항을 적용하기 쉬워진다.

 

 

깨끗한 테스트 코드

 

테스트 코드에서 가장 중요한 것은 '가독성'이다.

 

테스트 코드는 크게 세 가지 구조로 나누어 작성한다.

1. 테스트 자료를 만든다.
2. 테스트 자료를 조작한다.
3. 테스트 결과를 확인한다.

 

이 외에 잡다한 코드라인은 생략하고 필요한 유형의 코드만 작성한다.

이렇게 작성하면 테스트 코드의 기능을 정확하고 빠르게 이해할 수 있다.

 

 

테스트당 assert 하나

테스트 당 assert를 하나만 쓴다는 것은 내부 결론이 하나로만 나오기 때문에 코드를 이해하기 쉽고, 빠르다.

 

어떤 테스트 코드에서는 assert를 많이 사용해야 하는 테스트 코드의 경우 하나의 함수 안에 여러 assert를 부여해서 단순히 개수를 줄이는 것이 좋다고 생각한다라고 쓰여있다.

 

여기서 assert 문을 하나만 쓴다라고 하기보다, 하나의 테스트 코드는 한 가지의 개념에 대해서만 테스트해야 한다고 하는 것이 의도가 더 분명해 보인다.

 

하나의 테스트 코드 내에 여러 가지가 들어있다면 어떤 테스트에서 실패하고 있는지 모호해질뿐 아니라 테스트 코드 자체를 이해하는 것이 어려워질 수 있다.

 

F.I.R.S.T

깨끗한 테스트 코드는 다음과 같은 다섯 가지 규칙을 따른다/

First(빠르게): 테스트는 빨라야 한다. 테스트 코드를 자주 확인하면서 오류를 수정해 나가야 하는데 테스트가 느리면 그만큼 테스트를 자주 확인할 수 없으니 바로바로 문제를 해결하기 힘들다.

Independent(독립적으로) :  각 테스트는 서로 의존하면 안 된다. 각 테스트는 독립적으로 수행되어야 하며 다른 테스트에 의해 영향을 받으면 안된다.

Repeatable(반복 가능하게) : 어떤 환경에서도 반복 가능해야 한다. 테스트에 영향을 주는 환경요인을 제거하는 규칙인 것 같다.

Self-validating(자가검증) : 테스트는 성공/실패 bool 값으로 return 되어야 한다. 테스트 결과를 확인하고 그 결과가 무엇을 뜻하는지 찾아봐서는 안된다. 의도가 분명하고, 직관적인 결과가 나와야 한다.

Timely(적시에) : 테스트는 적시에 작성해야 한다. 단위 테스트는 실제 코드를 짜기 전에 작성한다.

 

나의 결론

TDD에 대한 개념은 멋사 교육을 들으면서 처음 접하게 되었고, 교육을 통해 테스트 코드도 작성해 보았다.

책에서 말한 대로 간단한 컴포넌트에서도 수많은 테스트 코드가 작성되는 것을 겪었고, 이번 장을 읽으면서 공감을 할 수 있었다.

 

아직 TDD 방식에 대해서 완벽하게 숙지하고,

완벽한 테스트 코드를 작성할 순 없지만 이번 장에서 중요하다고 강조한 부분을 명심하면서 테스트 케이스들을 작성해 나가야겠다.