Younghoe.Info v3

SI 현장에서 자동화 테스트를 적용하면서 테스트 작성 여부에 따라 개발자 성향이 바뀌는 모습을 경험할 수 있다. 같은 기반 기술을 사용하지만, 개발 일정이 달라 A 시스템과 B 시스템 개발자 투입 사이에 한 달 정도 공백이 있었다. 국내 SI에선 JUnit 테스트 작성을 필수 활동으로 삼고, 테스트 내용이 적절한가 까지 동료 검토 혹은 인스펙션하는 일은 흔치 않아 반발이 심하다. 우여곡절 끝에 개발이 한 달쯤 지나자 90% 가까이 테스트를 작성한다.

A 시스템 개발이 약 두 달쯤 진척했을 즈음의 일이다. 공통으로 사용하는 기반 코드(혹은 프레임워크)에 API 변경이 필요했다. 그래서, 거의 모든 DAO 클래스에 몇 줄이지만 변경이 필요했다. 공교롭게 개발 착수가 늦은 B 시스템 개발자에게 먼저 공지를 했다. 예상대로 상당한 반발을 겪을 수 있었다. 심지어 아직 완성한 DAO가 하나도 없는 개발자마저 변경 발생에 대해 불평을 토로했다. B 시스템 개발자는 한 달 남짓 새로운 개발환경(Spring과 X-internet 사용 기반을 공통화한 기반 코드 사용 및 화면 입력 데이터 및 DB 접근 로직에 대한 JUnit 작성)에 익숙해지는 중이었다.

긴 설득 과정에서 얻은 피로감을 안고 이번에는 A 시스템 개발자에게 공지했다. A 시스템 개발자는 두 달 전과 달리 수정사항에 대해 거부감이 확연하게 적었다. 단지, '바꿔야 하는 이유'와 '현재 방법이 가장 나은가?' 등을 확인해왔다. 안도감을  넘어서 고마움을 느낄 수 있었다. 태도 변화는 어디서 왔을까? 답은 확실했다. 우리는 TDD를 채용하지는 않았다. 무슨 말이냐면, 테스트를 먼저 만들지는 않는다. 사용자 입력 값과 DB 상태를 고려하여 서버측 로직이 정상작동 하는가를 확인하는 기능 테스트를 JUnit 기반으로 작성한다. 어차피 화면을 통해 제삼자가 테스트를 하기 때문에 JUnit이 제공하는 기능 검증 효과는 크지 않았다.^[각주:1] 가장 두드러진 효과는 회귀 테스트가 주는 이점이다.

이와 달리 눈에는 잘 띄지 않았지만, 훨씬 강력한 이점을 발견했다. 아직 대다수 개발자가 JUnit 테스트 작성에 서툴다 보니 동료 검토를 강화했다. 개발자가 코드를 작성하고 나면, 이슈 트래커(툴은 Redmine)를 사용하여 동료 검토를 요청한다. 코드 전체를 몇 사람이 나누어서 검토해주고 지적사항은 '결함'이나 '권고'로 다시 이슈 트래커에 올린다. 처음에는 개발자가 수정에 반감을 갖지만, 반복하다 보면 일상으로 변한다. 일상으로 변하면, 이유가 어떻든 더 나은 코드를 만들기 위해 수정을 수용한다. 회귀 테스트를 갖췄으니 리팩터링은 한결 수월하다. 자동화 테스트를 몇 달 이상 수행한 개발자는 분명히 그렇지 않은 개발자 혹은 테스트 수행하기 전보다 변화에 대해 관대했다. 물론, 테스트를 작성하지 않아도 동료 검토 과정을 통해 성향을 바꿀 수 있다. 하지만, 기준 부합 여부를 명확히 성공이나 실패로 판별해주는 방법이 있는 경우는 그렇지 않은 경우에 비해 확연히 유리하다.