테스트 코드 작성의 필요성

테스트 코드에 얘기하기 전에 우선 TDD라는 용어는 다들 들어봤을 것이다. TDD에 대해서 가볍게 설명한다.

 

TDD(Test Driven Development)란 테스트 방법론중 하나로 애플리케이션 코드보다 테스트 코드를 먼저 작성해서 테스트가 구현 과정을 주도하는 것이다.

 

 

TDD의 주기

• Red: 실패하는 테스트를 작성한다.
• Green: 테스트에 성공하는 코드를 구현한다.
• Refactor: 구현 코드를 리팩토링(중복 제거)한다.

TDD를 할 때 연산의 구현할지 확신이 들면 바로 정확한 구현을 해도 된다.

테스트를 할 때 우리에게 중요한 것은 작동하는 깔끔한 코드를 얻는 것이다. 이를 해결하기 위해서 나누어서 정복하자.

‘작동하는 깔끔한 코드’를 얻어야 한다면, ‘작동하는’ 부분을 먼저 해결하고 그 다음 ‘깔끔한 코드’부분을 해결하는 것이다.

 

 

단위 테스트(Unit Test)

단위 테스트는 모듈안에서 작은 코드 단위(클래스 or 메서드)를 독립적으로 검증하는 테스트다. 단위 테스트를 통해서 우리가 작성한 애플리케이션 코드가 예상대로 동작하는지 자동으로 테스트 한다. 작업 단위는 다른 모듈이나 라이브러리에 의존하지 않고 구분된 작업으로 볼 수 있으며 외부에 의존하지 않기 때문에 검증 속도가 다른 테스트에 비해서 빠르고, 안정적으로 테스트할 수 있다.

각 테스트는 다른 테스트와 완전히 격리되어 있어야 한다.

 

통합 테스트(Integration Test)

여러 모듈이 협력하는 기능들을 통합적으로 검증하는 테스트다. 애플리케이션은 여러 모듈들이 상호작용 하기 때문에 이 모듈들이 어떻게 통신하고 함께 작동하는지 테스트한다.

일반적으로 단위 테스트만으로는 애플리케이션의 전체 기능의 신뢰성을 보장할 수 없으므로 단위 테스트와 통합 테스트를 같이 사용해서 애플리케이션을 테스트한다.

 

 

테스트는 왜 필요할까?

테스트가 없을 때의 문제점

• 개발을 진행하다 보면 애플리케이션 코드에 기능이 추가되는 일들이 빈번하게 일어난다. 이 때 새로운 기능을 추가할 수도 있지만 기존 코드를 건드는 일도 생기게 되는데 개발을 했을 때 기존 코드가 정상적으로 동작하는지 확인하는 일이 필요하다.
• 테스트를 하지 않으면 이전 코드가 동작했었던 생각이나 자신의 감에 의존하게 되며 애플리케이션 로직을 직접 확인해보며 피드백을 하게된다. (정확성이 떨어진다.) 이렇게 되면 유지보수가 어려워지고, 버그가 발생할 가능성이 높아진다.

 

테스트로 얻는 이점

• 개발을 하면서 테스트를 하면 내가 무엇을 해야하는지(요구사항) 명확히 안다는 사실을, 스스로 지속적으로 확인할 수 있다.
• 테스트 코드는 내가 개발한 코드가 정상동작 하는지 빠르게 피드백을 얻을 수 있고, 매번 직접 테스트하는 것이 아닌 자동화 테스트를 진행할 수 있고, 수동 테스트에 드는 비용을 절약 가능하다.
• 테스트는 애플리케이션이 커지더라도 안정감있게 개발을 할 수 있게 해준다. 그리고 소프트웨어의 빠른 변화를 지원할 수 있다.
• 우리는 테스트 코드를 통해 요구사항에 대한 케이스를 테스트로 만들고 협업할 때 동료와 소스코드를 공유하고 소통해야 한다.

 

 

켄트 벡의 '테스트 주도 개발' 책에서 이런 문구가 있다. 나는 이 문구를 보면서 테스트 코드의 필요성이 와닿았던 것 같다.

 

우리가 개발을 하면서 엄청난 흥미를 가지고 새 프로젝트를 시작하고 시간이 지남에 따라 썩어가는 코드를 보게 된다. 시간이 흐르고 하루빨리 이 썩은 코드를 버리고 다음 프로젝트가 시작되기를 기다린다.

TDD는 시간이 지남에 따라 코드에 대한 자신감을 더 쌓아갈 수 있게 해준다. 테스트가 쌓여감에 따라(자신의 테스팅 기술이 늘어감에 따라) 시스템의 행위에 대한 자신감을 더 많이 얻게된다. 설계를 개선해 나감에 따라 점점 더 많은 설계 변경이 가능해진다. 프로젝트를 진행하면서 시간이 지난 후에 더 좋은 느낌을 갖을 수 있도록 TDD가 도와준다.

테스트 주도 개발 - 켄트 벡