테스트 코드에 대해ㅣ작성하는 이유, 단위 테스트&통합 테스트 특징, 작성하는 법, 좋은테스트 위한 5가지 속성

최근 개발을 할 때 테스트 코드로 로직을 확인하는 과정이 중요해지고 있다. 테스트 코드란 말 그대로 코드나 비즈니스 로직 자체를 테스트하기 위해 작성한 코드를 말한다. 심지어 애자일 방법론 중 하나인 '테스트 주도 개발(TDD : Test_Driven Development)'도 등장했다.

테스트 코드 작성 이유?

여러 이유가 있겠지만 테스트 코드의 장점에 대해서 몇 가지 말하면,

• 개발 과정에서 문제를 미리 발견할 수 있다.
• 리팩토링 리스크가 줄어든다.
• 애플리케이션을 가동해 직접 테스트하는 것보다 테스트를 빠르게 진행해볼 수 있다.
• 하나의 명세 문서로서의 기능을 수행한다.
• 몇 가지 프레임워크에 맞춰 테스트 코드를 작성하면 좋은 코드를 생산할 수 있다.
• 코드가 작성된 목적을 명확하게 표현할 수 있고, 불필요한 내용이 추가되는 것을 방지한다.

무엇보다 가장 큰 이유는, 문제를 미리 발견할 수 있다는 것일 것이다.

단위 테스트와 통합 테스트

테스트 방법은 여러가지가 있지만, 크게 나누면, '단위 테스트(Unit Teset)'와 '통합 테스트(Integration Teset)'로 구분할 수 있다.

• 단위 테스트 : 애플리케이션의 개별 모듈을 독립적으로 테스트하는 방식
• 통합 테스트 : 애플리케이션을 구성하는 다양한 모듈을 결합해 전체적인 로직이 의도한 대로 동작하는지 테스트하는 방식

단위 테스트 특징

단위 테스트는 테스트 대상의 범위를 기준으로 가장 작은 단위의 테스트 방식이다. 일반적으로 '메서드 단위'로 테스트를 한다. 테스트 비용도 적게 들기 때문에 테스트 피드백을 빠르게 받을 수 있는 장점을 가지고 있다.

통합 테스트 특징

통합 테스트는 모듈을 통합하는 과정에서 호환성 등을 포함해 애플리케이션이 정상적으로 동작하는지 확인하기 위해 하는 테스트 방식이다. 통합 테스트는 여러 모듈을 함께 테스트해서 정상적인 로직 수행이 가능한지 확인한다. 또한, 통합 테스트는 외부 요인들을 포함해 테스트를 진행해 애플리케이션이 온전히 동작하는지 테스트를 하게 된다. 다만 모든 컴포넌트가 동작해야 하기 때문에 테스트 비용이 커지는 단점도 있다.

테스트 코드

테스트 코드를 작성하는 방법은 다양하다. 하지만 그 중에서 가장 많이 사용하는 'Given-When-Then' 패턴과 'F.I.R.S.T' 전략을 알아보자!

Given-When-Then 패턴

Given-When-Then 패턴은 테스트 코드를 표현하는 방식 중 하나이다.

• Given
  : 테스트를 수행하기 전에 테스트에 필요한 환경을 설정하는 단계. 변수를 정의하거나 Mock 객체를 통해 특정 상황에 대한 행동을 정의.
• When
  : 테스트의 목적을 보여주는 단계. 실제 테스트 코드가 포함되고, 테스트를 통한 결과값을 가져온다.
• Then
  : 테스트의 결과를 검증하는 단계이다. 일반적으로는 When 단계에서 나온 결과값을 검증하는 작업을 수행한다. 결과값이 아니라도 이 테스트를 통해 나온 결과에 검증해야 하는 부분이 있다면 이 단계에 포함시켜야 한다.

Given-When-Then 패턴은 테스트 주도 개발에서 파생된 BDD(Behavior-Driven-DDevelopment : 행위 주도 개발)를 통해 탄생한 테스트 접근 방식이다. 단위 테스트보다는 많은 호나경을 포함하는 테스트하는 '인수 테스트'에서 사용하는 것을 추천한다고 많이들 말하지만 단위 테스트에도 활용할 수는 있다.

사실, 간단한 테스트로 보는 단위 테스트에서는 잘 사용하지는 않는다. 이유는 불필요하게 코드가 길어진다는 점 때문이다. 하지만 테스트 코드의 장점 중 하나인 '명세 문서'의 역할을 중요하게 생각한다면 고려해볼 만 하다.

F.I.R.S.T

F.I.R.S.T는 좋은 테스트를 작성하는 속성? 규칙? 정도를 의미한다. 단위 테스트에 많이들 적용하곤 한다.

• Fast - 빠르게
  : 테스트는 빠르게 수행되어야 한다. 테스트가 느리면 코드를 개선하는 작업이 느려져 코드 품질이 떨어질 수 있다.
• Isolated - 고립된, 독립된
  : 하나의 테스트 코든느 목적으로 여기는 하나의 대상에 대해서만 수행되어야 한다.
• Repeatable - 반복 가능한
  : 테스트는 어떤 환경에서도 반복 가능하도록 작성해야 한다. 즉, 테스트는 개발 환경의 변화나 네트워크의 연결 여부와 상관없이 수행되어야 한다.
• Self-Validating - 자가 검증
  : 테스트는 그 자체만으로 테스트의 검증이 완료되어야 한다. 만약 려과값과 기대값을 비교하는 작업을 코드가 아니라 개발자가 직접 확인하고 있다면 좋지 못한 코드일 것이다.
• Timely - 적시에
  : 테스트 코드는 테스트하려는 애플리케이션 코드를 구현하기 전에 완성되어야 한다. 너무 늦게 작성된 테스트 코드는 정상적인 역할을 수행하기 어려울 것이다. 또한 개발 비용도 커지기 쉽다. 다만, 이 부분은 테스트 주도 개발의 원칙을 따르는 테스트 작성 규칙으로, 테스트 주도 개발을 기반으로 개발을 하는 것이 아니라면 이 부분은 제외하기도 한다.