[Clean Code] 클린 코드(단위 테스트) - 14

단위 테스트

이전까지의 단위 테스트란 프로그램이 '돌아간다' 라는 사실만 확인하는 정도였다.
현재는 TDD와 애자일 덕분에 단위 테스트를 자동화하는 프로그래머들이 이미 많아졌으며, 늘어나는 추세다.

TDD 법칙 3가지

요즘엔 실제 코드를 작성하기 전에 단위 테스트부터 짜라고 요구한다!

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

이렇게 일하면 매일 수십개에서 매년 수천개의 테스트 케이스가 나온다.
하지만 정말 많아진 테스트코드는 심각한 관리 문제를 유발한다.

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

기존에 작성한 테스트 케이스를 위한 코드를 짰지만, 실제 코드는 계속해서 변경된다.
실제 코드가 변경됨으로써 이전에 작성한 테스트 케이스가 실패한다면 테스트 케이스를 통과시키기는 점점 더 어려워진다.
그렇게 유지되다보면 결국에는 테스트 케이스들을 모두 버리는 상황에 처한다.

BUT, 버린다면 실제 코드가 정상적으로 동작하는 지 확인할 수가 없다.
따라서 테스트 코드 또한 실제 코드만큼이나 중요하다!

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

테스트 코드를 깨끗하게 유지하지 않으면 잃어버린다.
유연성, 유지보수성, 재사용성을 제공하는 버팀목이 바로 단위 테스트이다. -> 테스트 케이스가 있으면 코드 변경이 두렵지 않으므로
하지만, 코드를 잘 짜도, 아키텍처를 유연해도, 설계를 잘 하더라도 테스트 케이스가 없으면 버그를 잡아내기 힘들다.

테스트 케이스의 커버리지가 넓을수록 코드 변경에 대한 두려움은 사라진다.

깨끗한 테스트 코드

세가지가 필요하다

1. 가독성
2. 가독성
3. 가독성
   (;;;;; 뭐야 왜이래)

테스트 코드에서의 가독성을 굉장히 중요하다.
테스트 함수 내에 테스트를 위한 사전 작업들 같은 경우는 별도의 함수를 통해 호출하여 가독성을 높인다.

이중 표준

테스트 환경에서는 성능을 크게 신경쓰지 않아도 된다.
성능보다는 가독성과 테스트에만 집중한다.

테스트당 assert 하나

굳이 지킬 필요는 없다

테스트당 개념 하나

이게 차라리 맞다.

F.I.R.S.T

• Fast: 테스트는 빨라야 한다. 초반에 자주 돌려야 문제를 찾기 쉽다.

• Independent: 각 테스트는 서로 의존하면 안된다. 한 테스트가 다른 테스트의 환경을 준비해서는 안된다. 테스트 함수는 순서와 상관없이 보장되어야 한다.

• Repeatable: 테스트는 반복 가능해야 한다. 실제 환경, QA 환경, 네트워크가 없는 노트북 환경에서도 실행되어야 한다.

• Self-Validating: 테스트는 Bool 값으로 결과를 내야 한다. 성공 아니면 실패!
  통과 여부를 Bool로 내지 않으면 판단은 주관적이 된다.

• Timely: 테스트는 적시에 작성해야 한다. 실제 코드를 구현하기 이전에! 작성되어야 한다.

결론

사실상 깨끗한 테스트 코드라는 주제는 정말 끝이 없는 주제이다.
실제 코드보다 더 중요할 수도 있다.
테스트 코드를 깨끗하게 유지하자.