클린 코드 - 단위테스트에 대하여

클린코드의 [단위 테스트] 부분에 대해 정리해보았다.

 

코드에서 테스트는 매우 중요한 부분이다.

테스트 작성에서 준수해야 할 것은 매우 많이 있으나, 클린코드의 기준에서 테스트를 정리한 책의 내용을 정리하였다.

 

• 테스트 당 개념하나

테스트에서도 코드에 작성하는 규칙을 준수하는 것처럼 다른 사람이 보았을 때 이해하기 쉬운 코드를 작성해야 한다.

예를 들어 함수가 지나치게 길거나 비슷한 개념이여도 연속으로 테스트하는 긴 함수는 피해야 한다.

개념마다 테스트를 분리하는 것이 좋으며 독자적인 개념마다의 테스트 갯수로 쪼개야 마땅하다.

 

아래는 위와 같은 긴 코드의 예시인데 클린 코드 p.166을 참조하면 좋겠다.

 

Public void testAddMonths(){

SerialDate d1 = SerialDate.createInstance(31, 5, 2004);

 

SerialDate d2 = SerialDate.addMonths(1, d1);

 

….

[클린코드 p.166 참조]

 

 

F.I.R.S.T.

FIRST는 테스트에서 깨끗한 코드를 작성하는 다섯가지 규칙으로,

 

빠르게(Fast), 독립적으로 (Independet), 반복가능하게 (Repeatable), 자가  검증(Self-Validation), 적시에(Timely)를 의미한다.

 

첫째로 빠르게는 당연히 테스트를 수행하는데 있어 지나친 시간이 걸리면 안되기 때문에 빠르게, 몇번을 반복해서 동작하더라도 빠른 속도로 수행되는 코드를 작성하는 것이 중요할 것이다.

 

둘째로 독립적으로 (Independent)으로는 테스트 코드는 각 다른 테스트 코드를 의존해서는 안된다는 것이다. 각자가 독립적인 개념을 갖추고 수행했을때 성공/실패가 결정나야 하며 의존성을 가져서 다른 테스트에 의지하면 안된다. 이는 일반적인 기능을 구현할때 코드를 작성하는 규칙과도 동일하다.

 

반복가능하게 (Repeatable)는 테스트 코드는 당연히 계속 여러번 수행되어야 하는데, 어떤 것이 생성되고 삭제되지 않는다던가, 이전의 테스트가 그 다음의 테스트에 영향을 미친다면 올바른 테스트 환경을 구축한 것이 아니게되어 테스트가 의도한 대로 동작하지 않고 정상적으로 구현을 하게 되었을때도 실패하는 현상이 발생할 것이다.

이에 따라 @BeforeEach, @AfterEach 를 사용한 환경을 구성하는 것과 같이 필요하다면 적절한 전처리와 후처리를 진행해야 한다.

 

자가검증하는(Self-Validation), 는 부울 값으로 결과를 내야한다 (성공/ 실패)는 의미와, 다른 파일에 의존해서 결과를 처리해서는 안된다는 것이다. 예를 들어통과 여부를 알기 위해 다른 로그 파일을 읽게 한다던가 해서는 안되며, 통과/실패 여부를 보려고 텍스트 파일 두개를 수작업으로 비교하게 만들어서도 안된다. 이런 작업을 통해 테스트를 수행한다면 결국에는 판단은 주관적으로 되며 지루한 수작업 평가가 필요하게 된다 - 이는 엑셀이나 사용한 파일에 의존성을 갖게 되고 실패나 성공했을 경우에도 해당 파일을 열어서 값을 비교해야 하거나 해야 할 가능성이 생긴다는 뜻이다. 즉 테스트가 스스로 성공과 실패를 가늠하지 않으면 안된다는 결론이 결과적으로 나오게 된다.

 

마지막으로 적시에(Timely)는 단위 테스트는 테스트하려는 실제 코드를 구현하기 직전에 구현해야 한다는 것이다.

실제 코드를 구현한 다음 테스트 코드를 만들면 실제 코드가 테스트하기 너무 어렵다는 사실을 발견할지 모르며 어떤 코드는 테스트하기 너무 어렵다고 판명날지도 모른다. 혹은 설계를 수행할 때 테스트가 불가능하도록 실제 코드를 설계할지도 모르기 때문에 테스트를 먼저 작성하고, 그에 따라 코드를 구현하는 것은 좋은 습관이라 할 수 있을 것이다.

 

클린코드 책을 읽으며 테스트 코드에는 한 장으로 설명하기 어려운 내용들이 있어 테스트 주도 개발을 추후 읽어보고, 리팩토링이나 다른 고전 도서와 결합해서 더 나은 코드를 짜려는 노력을 진행해 봐야 겠다.

항상 남에게 설명할 수 있을 때까지 공부를 시도해보려는 노력을 진행해봐야겠다는 생각이 들었다. 그동안은 기피해왔었지만 그중 하나의 가장 좋은 방법은 글을 쓰는 것일 것이다.

 

본론으로 다시 돌아가

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

테스트 코드는 실제 코드의 유연성과 유지보수성, 재사용성을 보존하고 다른 사람이 코드를 변경하기 쉽도록 만든다.

 

따라서 테스트 코드는 지속적으로 재사용으로 가능하도록 깨끗하게 관리해야한다.

표현력을 높이고 간단하게 정리해야 한다.

 

테스트 API를 구현해 도메인 특화 언어를 만들자. (DSL)

 

그러면 그만큼 테스트 코드를 짜기가 쉬워진다.

 

이 말의 의미는 해당 구현하는 도메인에 맞추어 이름과 함수등, 혹은 API를 설정하고 그것을 기반으로 테스트를 구현해나가면 마치 하나의 프레임워크를 새로 구현해나가는 것처럼 테스트 코드를 유지보수, 새로 짜기 쉬워진다는 의미로 이해하였다.

이와 같은 체계를 구축하면 좀 더 도메인 지식에 명확한 코드들을 빠르게 테스트하고, 굳건하고 강건한 코드들을 구현할 수 있을 것 같다는 생각이 들었다.

 

기억하자면, 테스트 코드가 방치되어 망가지면 실제 코드도 망가지기 때문에 항상 테스트의 유지보수에도 신경써야 할 것이다.