TDD로 학습 테스트 (라이브러리 사용법부터 오픈소스 기여까지)

많은 프로젝트에서 외부 라이브러리를 사용한다. 라이브러리는 작업 시간을 아껴주기 때문에 팀원들의 동의가 있고, 해결하려는 문제에 도움이 된다면 사용하는 편이다.
 
[테스트 주도 개발] 책에서는 학습 테스트에 대한 설명이 있다. 학습 테스트는 외부에서 만든 소프트웨어를 처음 사용할 때, 해당 소프트웨어의 기능을 테스트 코드에서 사용해 보는 것을 말한다. 학습 테스트를 작성하면 아래와 같은 효과를 볼 수 있다.

라이브러리 사용법을 학습한다

문자 그대로 학습 테스트는 라이브러리의 사용법을 '학습'하기 위해서 작성한다. 나머지는 추가로 얻는 보너스 효과이다.
 
라이브러리는 많은 기능을 제공한다. 이 중에 프로젝트에서 사용하는 기능에 대해서만 학습 테스트를 작성한다. 라이브러리의 모든 기능을 학습 테스트로 작성하는 것은 시간 낭비다. 라이브러리가 10개의 기능을 제공하고, 프로젝트에서 2개의 기능만 사용한다면, 2개의 기능에 대해서만 학습 테스트를 작성한다. 나중에 라이브러리의 3번째 기능이 필요하다는 것을 알았다면, 그때 가서 학습 테스트를 추가한다.
 
테스트 데이터는 가장 단순하고 일반적인 데이터를 사용한다. 필요하다면, 특이한 데이터를 사용해서 작성할 수도 있다.
 

프로젝트 맞춤형 라이브러리 매뉴얼이 생긴다

새로운 기술은 익숙해지기까지 시간이 걸린다. 학습 테스트가 있으면 새 기술의 사용법이 헷갈릴 때마다 참고할 수 있다. 사용법을 공식 문서나 책에서 찾는 것보다, 학습 테스트로 확인하는 것이 더 경제적이다. 특히, 자신이 작성한 학습 테스트를 읽을 때는, 작성했을 당시의 기억이 함께 떠올라서 리마인드 하기 더 쉬웠던 거 같다. 이렇게 몇 번 반복하다 보면 참고할 필요가 없어져서, 매뉴얼로서의 가치가 떨어지겠지만, 신규 입사자나 다른 개발자에게 필요할 수도 있다.
 
개인 프로젝트에 프로그래밍 언어, 라이브러리, 프레임워크를 모두 처음 사용하는 기술로 적용한 경험이 있다. 이때 학습 테스트가 많은 도움이 됐다. 프로그래밍 언어의 문법과 기본 API의 사용법을 가장 많이 참고했고, 그다음으로 라이브러리의 사용법을 참고했다. 프레임워크에 대한 학습 테스트는 작성하지 않았다. 프레임워크의 '사용법'을 테스트 코드로 만드는 방식을 찾지 못했었다. 영속성 기능에 대한 통합 테스트 작성해서, 기능의 동작 여부를 확인했지만, 프레임워크의 사용법과는 무관했다.
 

라이브러리 버전 마이그레이션에 자신감을 가질 수 있다

내가 당황했던 버그 중 하나는 라이브러리 버전과 관련이 있었다. React.js를 사용한 프로젝트로 작업할 때의 경험이다. 해당 프로젝트는 '롤링 슬라이드' 기능을 위해서 외부 라이브러리를 사용했고, 이 라이브러리는 메인 페이지 상단의 띠 배너에서 사용했다. (메인 페이지와 관련 없는) 기능을 수정하고, 스테이지 서버에서 최종 확인 후 프로덕션 서버에 배포했다. 프로덕션 메인 페이지를 접속해 보니 띠 배너의 UI가 깨져있었다.
 
해당 프로젝트는 외부 라이브러리 버전에 caret(^) 기호를 붙여서 사용하고 있었다. Node.js에서 caret 기호가 붙은 버전은 마이너 버전까지 자동으로 업데이트된다. 버그의 원인은 스테이지 배포와 프로덕션 배포 사이에 '롤링 슬라이드' 라이브러리의 버전이 업데이트된 것이었다. 🥲
 
학습 테스트를 작성하면 라이브러리 버전을 마이그레이션 하는데 안정감이 생길 수 있다. 배포 프로세스에서 테스트 코드 실행하면 기능의 동작 여부를 검증할 수 있다. 안정화된 라이브러리 버전은 업데이트하는 편이 좋다. 성능이 개선되거나 보안 패치가 적용될 수 있고, 신규 기능을 사용할 수도 있기 때문이다.
 

오픈소스 프로젝트에 기여할 수도 있다

[Ta4j]라는 Java로 작성된 기술적 분석 라이브러리를 학습하고 있었다. 해당 라이브러리는 두 지표의 교차 여부를 판단하는 기능을 제공한다. 지표는 배열처럼 순서와 값이 있는 자료 구조이다.
 
테스트 데이터로 'A 지표'는 10이라는 고정값을 사용하고, 'B 지표'는 [9, 10, 10, 10, 11]를 사용했다. 지표가 임곗값(10)에 머물다가 벗어났을 때 어떻게 작동하는지 확인하고 싶었다. 이 테스트 예상과 다르게 동작했고, 라이브러리 소스코드를 확인해 보니 로직에 버그가 있었다. 버그 수정 후 PR을 요청했고 다음 배포 버전에 반영됐다. 다른 오픈소스도 이런 로직이 숨어 있을 수 있다.
 

마치며

개인 프로젝트를 진행한다면 최대한 학습 테스트를 작성하는 것을 추천한다. 개인 프로젝트는 가끔 시간 날 때 작업하는 경우가 많다. 심지어 반년에 한 번 기능을 수정하는 경우도 있을 것이다. 라이브러리 버전을 따라가기 위해서라도, 개인 프로젝트는 학습 테스트를 작성하는 편이 좋다.
 
팀 프로젝트를 진행한다면 팀원들과 공감대를 형성해야 한다. 학습 테스트를 작성하고 관리하는 데 비용이 들기 때문이다. 그래도, 투자 대비 이익이 크다면 적용하는 편이 좋다.