단위 테스트

애플리케이션 실행에는 무수히 많은 변수가 존재합니다. 이러한 변수 상황을 효율적으로 대처하기 위해 테스트의 중요성은 시간이 지날수록 꾸준히 증가하였고 지금은 TDD라는 용어까지 나오며 테스트가 필수적으로 되었습니다.

 

형식 맞추기로 테스트를 급하게 작성해서는 안 되고 제대로 된 테스트 케이스를 작성할 수 있도록 테스트에 많은 시간을 투자해야 합니다.

TDD 법칙 세 가지

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

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

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

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

지저분한 테스트 코드는 개발 비용을 증가시킵니다. 핵심 로직에 투자해야 할 시간을 테스트 코드 유지보수에 사용하게 되는 문제가 발생합니다. 따라서 테스트 코드는 실제 코드만큼 중요하다는 생각을 가지고 품질에 신경 써서 작성하도록 해야 합니다.

 

테스트는 유연성, 유지보수성, 재사용성을 제공합니다. 적절한 테스트 케이스는 아키텍처를 믿을 수 있게 해주고 개선할 수 있게 도와줍니다.

깨끗한 테스트 코드

깨끗한 테스트 코드를 위해 가장 중요한 것은 가독성입니다. 가독성을 위해 테스트 코드를 작성하는 패턴이 존재하는데 BUILD-OPERATE-CHECK 패턴입니다. 이는 GIVEN-WHEN-THEN으로 사용하기도 합니다.

 

첫 부분은 테스트 자료를 생성합니다. 두 번째 부분은 테스트 자료를 조작하며, 세 번째 부분은 조작한 결과가 올바른지 확인합니다.

테스트 당 assert 하나

테스트 코드를 작성할 때 함수마다 assert 문을 단 하나만 사용하는 것을 권장합니다. 테스트의 결론이 하나라 이해하기 쉽고 빠르다는 장점이 존재하기 때문입니다.

 

필요에 의해 여러 assert 문을 넣는 경우도 존재하지만, 개수를 최대한 줄이는 편이 좋습니다. 이를 조금 발전시켜 테스트 당 개념 하나로 이해하는 편이 좋습니다. assert 문이 여러 개인 것이 문제가 아니라 테스트 의도와 달리 여러 개를 테스트하는 것이 문제이기 때문입니다. 테스트하고자 하는 개념을 명확하게 지정 후 테스트하도록 해야 합니다.

F.I.R.S.T.

Fast

테스트는 빨라야 합니다. 테스트가 느리면 테스트에 대한 집중이 떨어지게 됩니다.

Independent

각 테스트는 독립적으로 수행되어야 합니다. 의존하게 되면 실패했을 때 의존 관계에 있는 모든 테스트를 확인해봐야 하고 이는 원인을 찾기 어렵게 만듭니다.

Repeatable

테스트는 어떤 환경에서도 반복할 수 있어야 합니다. 실제 환경, 개발 환경, 네트워크가 연결되지 않은 환경에서도 실행할 수 있어야 합니다.

Self-Validating

테스트의 결과는 부울값으로 나와야 합니다. 테스트 스스로 성공과 실패를 가늠하지 않는다면 판단은 주관적이고 지루한 수작업 평가가 필요하게 됩니다.

Timely

테스트는 적시에 작성해야 합니다. 실제 코드를 구현하기 직전에 구현해야 합니다. 그렇지 않으면 실제 코드의 테스트 구현이 어려운 상황이 발생할 수도 있습니다. 극단적으로는 테스트할 수 없도록 실제 코드가 작성될 수도 있습니다.

마치며

테스트 코드 작성을 직접 해보았을 때 실제 코드를 작성하는 것만큼 많은 시간을 사용하게 되었습니다. 프로젝트의 개발을 늦추게 될 수도 있지만 장기적으로 봤을 때 프로젝트의 완성도를 높이고 개발 시간을 앞당기는 것이 테스트 코드임을 다시 한번 이해하게 되었습니다. 개발을 진행할 때 테스트 코드의 중요성을 생각하며 깨끗한 테스트 코드를 작성할 수 있는 프로그래머가 되기 위해 노력할 것입니다.