[Clean code] chapter 9. 단위 테스트

Overview

단위 테스트에 대해서 알아보자.

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

테스트 코드를 대충 작성, 완벽하게 작성하지 않는 것은 작성하지 않는 것보다 더 좋지 않다. 대충 작성한 테스트 코드는 코드 변경에서 테스트 실패가 나오게 되고 더럽게 짜진 코드를 수정해서 해당 테스트를 통과하기는 더욱 어려워져 부담으로 남겨진다.

결국 테스트를 더 이상 작성하지 않거나 코드를 수정하지 않게 된다.

하지만 결국 테스트 코드와 멀어지고 테스트 코드를 버리게 되면 코드 수정에 대한 부담이 커지게 된다. 이전에 동작했던 로직이 잘 동작하는지 확인할 수 있는 방법이 없다. 결국 결함율을 높이게 된다.

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

테스트 코드에 작성되어 있다면 변경에 대한 두려움이 없다. 잘 작성되어 있다고 가정했을 때 말이다.

만약 아키텍처가 잘 구성되어 있지 않더라고 하더라도 테스크 코드가 잘 작성되어 있다면 변경에 대해서 두렵지 않다. 오히려 아키텍처를 변경하는데 더욱 쉽게 변경을 할 수 있다.

깨끗한 테스트 코드

깨끗한 테스트 코드를 만들기 위해서는 결국 가장 중요한 것은 가독성이다. 가독성을 실제 코드보다 테스트 코드에서 더 중요하다.

가독성을 위해서 Build-Operate-Check 패턴과 같이 구조를 만드는 것을 추천한다. 첫번째는 테스트 코드를 위한 재료를 만들고, 두번째는 테스트를 진행하고, 세번째는 그것을 검증한다. 이 방법은 여러 다양한 코드를 명확하게 구분짓기 때문에 어떤 것을 테스트하고 어떤 것을 검증하려고 하는지 빠르게 확인할 수 있다.

도메인에 특화된 테스트 언어

우리는 테스트를 편하게 하기 위해서 함수와 유틸리티를 만들어서 테스트 코드를 작성한다. 그렇게 되면 나중에 테스트 읽어볼 독자를 도와주는 역할을 한다. 그런 테스트 언어가 된다.

이중 표준

실제 코드에서 적용되는 표준과 테스트에 적용되는 표준은 다르다. 단순하고 간결하고 표현력이 풍부해야 하지만 실제 코드만큼 효율적인 필요가 없다.

테스트 코드는 실제 환경에서 동작하는 것이 아니라 테스트 환경에서 동작하기 때문에 요구사항과 판이하게 다르다.

시스템 프로그램을 만든다고 하더라고 실제 테스트 코드가 프로덕트에서 동작하는 것이 아니기 때문에 효율적보다는 가독성을 신경쓰는 것이 더 좋다.

테스트당 assert 하나

이 부분은 테스트 함수마다 한 개념만 테스트하라는 규칙이 더 낫겠다. 이것저것 잡다한 개념을 연속으로 테스트하는 긴 함수는 피한다.

우리가 테스트하고 싶은 것을 명확하게 생각하고 있다면 여러 assert를 써서 라도 정확하게 검증하면 된다.

F.I.R.S.T

빠르게: Fast

테스트는 빨라야 한다. 빨리 돌아야 테스트를 동작시키는데 있어서 두려움이 없다.

독립적으로: Independent

각 테스트는 의존하면 안된다. 테스트 환경에 따라서 테스트 순서가 어떻게 될지 모르고 그 과정에서 테스트가 망치게 될 수 있다. 그리고 그것을 통해서 결함이 숨겨질 수도 있다.

그러기 때문에 반드시 테스트 간에는 서로 의존적이면 안된다.

반복가능하게: Repeatable

테스트는 어떤 환경에서도 반복 가능해야 한다. 실제 환경, QA, 버스를 타고 집에 가는 길에도 실행 가능해야 한다.

자가검증하는: Self-Validating

테스트는 부울 값으로 결과를 내야 한다. 성공 아니면 실패다. 통과 여부를 알려고 로그 파일을 열거나, 파일 두개를 비교하면 안된다.

적기에: Timely

테스트는 적시에 작성해야 한다. 단위 테스트는 테스트하려는 실제 코드를 구현하기 직전에 구현한다. 구현 이후에 테스트 코드를 만들면실제 코드가 테스트하기 어렵다는 사실을 발견할지도 모른다. 테스트가 불가능하도록 만들어지도록 구현했을 수도 있다.

결론

테스트 코드는 실제 코드만큼이나 프로젝트 건강에 중요하다. 어쩌면 더 중요할 수도 있다.

테스트를 방지하면 테스트가 망가지고 실제 코드도 망가진다. 테스트 코드를 깨끗하게 유지하자.

key point

• 테스트는 실제 코드에 굉장히 큰 영향을 끼친다.
• 테스트 코드는 코드를 변경할 수 있는 힘을 만들고 그것을 통해서 프로덕트는 더욱 건강해질 수 있다.

마무리

해당 부분은 2019년 1월 인턴을 진행하면서 엄청나게 많이 읽었었다. 하지만 지금 읽으니 참 보이는 게 다른 것 같다.

그때 당시에 변경이 중요한지 몰랐고 왜 테스트가 중요한지 몰랐는데 지금보니 왜 테스트 코드가 중요한지 알겠다.