느낀 점 먼저

바로 얼마 전 TDD를 이용한 토이프로젝트를 진행한 적이 있어서 더 관심있게 읽었다.

책에 나온 TDD 법칙 세가지는 나름 지켜가며 프로젝트를 진행했지만, 나머지 내용들도 잘 준수했는지는..솔직히 잘 모르겠다...
세가지의 법칙도, 처음 개발할 때에는 잘 지켰지만 프로젝트를 진행하며 코드를 고칠 때에는 실제 코드를 먼저 고치고 그에 맞춰서 테스트 코드를 수정했던 것 같다...

내가 느꼈던 TDD의 장점은 Low Level의 코드부터 작성하기 때문에 프로젝트 도중 발생하는 관련 메소드 리팩토링 비용이 감소했다는 것과, 실제 코드를 변경하지 않고 다양한 케이스를 테스트 해볼 수 있다는 것이었다.

가독성?

간단한 기능을 구현하는 프로젝트였기 때문에 테스트 코드 역시 가독성은 나쁘지 않았다.

최소한의 assert?

하나의 assert으로 오류를 찾아낼 수 없어서 두 개 이상의 assert을 사용한 부분들이 존재한다. 실제 메소드에 각각 대응하는 테스트 코드를 작성하는 방식으로, 메소드의 기준으로 테스트 코드를 작성했기 때문이라고 생각한다. 메소드에 여러개의 기능과 로직이 있을 때 하나의 assert으로 모든 과정의 결과를 검증하기 어려웠던 것이다.
더 나아가서는 하나의 메소드에서 여러 개의 기능과 로직을 담당하는 것부터가 문제였을 수도 있다는 생각이 들었다.🧐

깨끗한 테스트 코드?

코드를 리팩토링하면서 테스트 코드보다 실제 코드를 먼저 작성한 경우도 있었다. 이 경우에는 코드를 작성하고 보니 테스트가 불가능한 코드여서 다시 작업한 적도 있다.
실제 코드 수정 - 테스트 코드 수정 불가 - 실제 코드를 테스트에 맞춰 수정 - 테스트도 수정의 순서로 진행한 것이다...

책에서 말한 것과 같이 테스트 케이스의 유지 보수 비용이 증가했다.
원인은 역시 테스트 코드가 클린하지 않게, 하나의 테스트에 여러 개의 기능이 있었던 탓 같다. 또, 테스트 코드가 명료하지 않아서 코드를 다시 분석하고 이해해야 했고, 코드가 단순하지 않기 때문에 수정해야할 부분도 여러 곳 발생했다.

오늘 읽은 내용을 바탕으로 TDD 기반의 프로젝트를 한번 더 진행해보고 싶어졌다.

내가 진행했던 토이프로젝트는 완성 후 한두번 리팩토링하고 나면 완료나 다를 바 없기 때문에, 실제 서비스가 되지 않는 프로젝트에서도 TDD가 유용할지 의문이 들었었다.
하지만 책을 읽으면서 생각해보니 조금 더 깨끗하고 적절한 테스트 코드를 작성했었더라면, 더 효율적인 프로젝트 진행이 되었을지도 모른다고 생각했다.

반성의 시간...

---

---

내용 요약

TDD 법칙 세 가지

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

위의 세가지 규칙을 따르면 개발과 테스트가 매우 짧은 주기로 반복된다.
이대로 계속 진행한다면 실제 코드를 사실상 전부 테스트하는 테스트 케이스가 나온다. 하지만 실제 코드와 맞먹을 정도로 방대한 테스트 코드는 심각한 관리 문제를 유발하기도 한다.

깨끗한 코드 유지하기

지저분한 테스트 코드를 작성하는 것은 오히려 테스트를 하지 않는 것보다 못하다.

코드의 변동이 생기면 테스트 코드도 변경되어야하는데, 테스트 코드가 복잡할 수록 실제 코드를 변경하는 시간보다 테스트 코드를 변경하는 것이 더 어려워진다.
실제 코드를 변경해서 기존 테스트 코드를 실패하기 시작하면, 테스트 코드는 점점 더 어려워지고 늘어난다. 따라서 새 버전을 출시할 때마다 테스트 케이스에 드는 유지 보수 비용도 늘어난다. 결국 테스트 슈트를 폐기해야하는 상황에 처한다.

하지만 테스트가 없으면 결함을 찾아내고 코드를 검증할 수 없고, 결함율이 높아진다. 결함이 많아지면 개발자는 변경을 주저하게 되고 코드가 점차 망가지게 된다.

결론은, 깨끗한 단위 테스트 코드를 짜야 한다는 것이다. 테스트 코드는 사고와 설계와 주의가 필요하다. 실제 코드 못지 않게 깨끗해야한다.

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

제대로 된 테스트 코드가 있으면 변경이 쉬워지기 때문에 유연성, 유지보수성, 재사용성을 제공한다.
반대로 테스트 코드가 지저분하면 코드를 변경하는 능력이 떨어지며 코드 구조를 개선하는 능력도 떨어진다.

깨끗한 테스트 코드

깨끗한 테스트 코드를 만드려면 가독성이 가장 중요하다.
가독성은 실제 코드보다 테스트 코드에서 더욱 중요하다. 가독성을 높이기 위해서는? 명료성, 단순성, 표현력이 필요하다.
테스트 코드는 최소의 표현으로 많은 것을 나타내야 한다.

테스트 당 assert은 최대한 줄인다

테스트 당 assert은 하나만 사용해야한다고 주장하는 의견이 있는데, 가혹하다고 느껴질 수 있지만 확실히 장점이 있다. assert문이 단 하나인 함수는 결론이 하나라서 코드를 이해하기 쉽고 빠르다.
이렇게 테스트를 분리하면 코드의 중복이 많아진다. 이것은 TEAMPLATE METHOD 패턴을 사용하면 중복을 제거할 수 있다. givem/when 부분을 부모 클래스에 두고 then 부분을 자식 클래스에 두면 된다. 하지만 이런 방식은 코드가 과도하게 많아질 수 있다.
이처럼 필요성에 따라 하나의 함수에 여러 assert문을 넣을 수도 있지만, assert문의 개수는 최대한 줄여야 좋다.

테스트 당 개념 하나

여러개의 개념을 연속으로 테스트하는 긴 함수는 피한다. 여러 개념을 하나의 함수로 몰아넣으면 각 코드의 이유와 각 절이 테스트하는 개념을 모두 이해해야 한다.

F.I.R.S.T.

깨끗한 테스트는 다음 다섯가지 규칙을 따른다.
1. Fast
테스트는 빨라야 한다. 테스트가 느려서 자주 돌리지 않으면 초반에 문제를 찾아내거나 쉽게 정리하지 못한다.
2. Imdependent
각 테스트는 독립적이어야 한다. 서로 의존하면 안된다. 어떤 순서로 실행해도 괜찮아야 한다. 테스트가 서로에게 의존하면 하나가 실패할 때 나머지도 연달아 실패하기 때문에 원인을 찾아내기 힘들고 결함이 숨겨진다.
3. Repeatable
테스트는 어떤 환경에서도 반복 가능해야 한다. 실제 환경, QA 환경, 네트워크가 없는 환경 등에서도 실행할 수 있어야 한다. 환경 때문에 테스트가 실패하는 경우가 있어서는 안된다. 또, 환경이 지원되지 않기에 테스트를 수행하지 못하는 일이 없도록 해야 한다.
4. Self-Vaildating
테스트는 자가검증 할 수 있어야한다. 테스트는 Bool 값으로 결과를 내야 한다. 통과 여부를 알기 위해 로그 파일을 읽게 되면 안된다. 텍스트를 직접 비교해서도 안된다. 테스트가 스스로 성공과 실패를 가늠하지 않는다면 판단은 주관적이 되며 수작업이 필요하게 된다.
5. Timely
테스트는 적시에 작성해야 한다. 단위 테스트는 테스트하려는 실제 코드를 구현하기 직전에 구현한다. 코드를 구현한 뒤에 테스트 코드를 만들면 실제 코드가 테스트하기 어려운 코드가 될 수도 있다. 실제 코드가 테스트가 불가능하도록 먼저 짜여질 수 있다.

결론

테스트 코드는 실제 코드만큼이나 프로젝트에 중요하다. 테스트 코드는 실제 코드의 유연성, 유지보수성, 재사용성을 보존하고 강화하기 때문이다.
테스트 코드는 지속적으로 깨끗하고 간결하게 정리하고 관리해야 한다.
테스트 API를 구현해 도메인 특화 언어를 만드는 것도 좋다.