현재 회사의 코드에 테스트 코드가 없었는데 작년 말부터 얘기가 나와서 테스트 코드 도입을 맡게 되었다. 처음 테스트 코드를 도입하면서 여러번 테스트 코드를 뜯어 고쳤다. 그 경험을 적고자 한다.
정렬, 사칙연산, 문자찾기 같은 프로그램 내부 연산만으로 결과가 나오는 로직의 테스트 코드를 작성하는 것은 생각만큼 단순하다.
// Given
a = [1,5,3,9,2]
// When
a.sort()
// Then
assertEqual(a, [1,2,3,5,9], "Not sorted!!")하지만 우리들의 많은 함수는 Server, APP, WEB, DB 간 통신으로 이루어진게 많다.
이러한 Client와 Server 간 통신하는 함수를 테스트 하고 싶다.
TDD를 처음 경험해보는 사람들이 하는 가장 흔한 실수는 실제 Server를 호출하는 것이다. 그렇게 할 경우 TEST 비용이 커지고, 네트워크 상태에 따라서 테스트가 실패하는 경우도 발생할 수 있다. 기본적으로 테스트 코드는 로직을 검증하는 것이기에 네트워크 등 다른 외부적인 요인으로 인해 실패하는 경우는 없어야 한다.
처음 서버 간 통신에 대한 테스트 코드를 작성할 때에는 대상 서버의 *stub을 만들어서 테스트를 하려고 했다. 그렇게 했더니 테스트 코드 작성에 많은 시간과 상당한 양의 코드 라인이 생성됐다.
방향을 바꿔서 외부 모듈에서 import해서 사용하는 서버간 통신을 하는 함수를 interface를 이용해 의존성을 주입하고 테스트에서는 해당 함수를 *mock해서 parameter들을 체크하고 이상이 없으면 지정된 response를 return하게 했더니 한결 수월하게 테스트 코드를 작성할 수 있었다.
- stub vs mock
stub은 모든 기능 대신 일부의 기능을 임의로 만드는 것이다.
mock은 실제와 동일한 기능을 하지는 않지만 이런식으로 동작할 것이다라고 알려주는 것이다.
테스트 코드를 작성하는 것은 러닝커브, 생산성 등의 측면에서 분명 안좋은 점이 있다. 그렇기에 SI회사 같은 코드의 퀄리티보다 기한이 중요한 곳에서는 사용하는 경우가 거의 없다고 한다.
하지만 테스트 코드를 사용하면 여러 장점들이 있다.
- 테스트 가능한 코드는 좋은 설계를 갖고 있다.
- 리팩토링할 때 상당히 좋다.
- 코드에 대한 피드백을 많이 받을 수 있다.
- 코드의 작성자 이외에 다른 사람이 유지보수를 할 때 테스트 코드를 보고 동작을 파악하기 좋다.
등등..
좋은 구조를 가진 코드가 테스트 하기 좋은것은 아니지만, 테스트하기 좋은 코드는 좋은 구조를 갖고 있다고 한다.
앞으로 코드를 구현하기 전에 테스트 코드를 먼저 작성하는 개발문화를 정착시켜야겠다.
