반응형


제목을 조금 자극적으로 써봤습니다.
여러분은 테스트코드란 무엇이라고 생각하시나요?

제가 소프트웨어 엔지니어로 일을 시작하고나서, 저에게 가장 큰 깨달음을 준건 "테스트코드" 입니다.

대부분의 회사에 그렇듯 제가 재직중인 회사에도 Legacy 프로젝트가 존재합니다.
여전히 Core 한 로직들이 Legacy 프로젝트에서 동작중이죠. 

최근에 작성된 프로젝트들의 경우에는 테스트코드 커버리지가 꽤 높습니다.
하지만, Legacy 프로젝트의 경우 테스트코드 커버리지가 거의 0에 가까웠습니다.
Legacy 프로젝트는 코드를 읽고 완전한 로직을 파악하기까지 꽤나 많은 시간이 필요합니다.
코드가 서로 얽혀있고, 모듈화 되지 않았기 때문입니다. 그리고 통합 테스트 도구의 부족으로 FeatureTest, 그리고 UnitTest 조차 어렵게 만듭니다.

스파게티코드지만, 요구사항을 만족하고 정상적인 기능이 동작하는 Legacy 프로젝트가 존재한다고 가정해봅시다.
이때, Legacy 이전 작업을 해야하는Jira Ticket 을 받았다면 어떨까요?
눈앞이 깜깜할지 모릅니다. 기능단위로 로직을 파악하는 것도 쉽지 않을 것입니다.

하지만 만약, 테스트코드가 존재한다면 어떨까요?

기본적인 응답과 로그를 검증해주는 테스트 코드가 존재한다면, 해당 테스트 코드를 기반으로 기능 로직을 파악하는 것이 훨씬 수월할 것입니다. 또한, Legacy 이전을 하지 않더라도, 리팩토링 혹은, 기능변경으로 인한 수정을 진행할 때도, 테스트코드는 우리에게 정말 좋은 안전장치가 되어줄 것입니다.

Legacy에서 테스트를 작성할 때, 고려해야할 사항은 다음과 같습니다.

  • 테스트용 데이터를 직접 생성
  • 테스트용 데이터를 직접 삭제
  • 테스트 로직 수행 중 생성되는 로그나 부가 데이터들을 테스트 후 직접 삭제하여 DB 무결성 유지

테스트용 트랜잭션을 지원하지 않기 때문에 테스트코드를 작성하는데 시간이 꽤 많이 걸릴지도 모릅니다.

그러면 이러한 질문이 생길 수 있습니다.

테스트코드 작성 비용이 너무 큰 것 아닌가요?

이것은 Legacy를 이전할지 말지에 대한 지표로 삼을 수 있습니다.
팀 내에서 기준을 잡고, 특정 기준보다 테스트코드 작성 비용이 너무 크다면 Legacy 이전을 적극적으로 고려해봐야 할 타이밍입니다.

 하지만 저는 Legacy 이전을 계획하더라도, 테스트코드를 작성 하는편이 더 효율적일 것이라고 생각합니다.
예를 들어 FeatureTest를 작성한다는 것은 결국, 기능단위로 해당 로직을 완벽히 파악해야한다는 것이고, 좋은 테스트코드를 작성하기 위해서는 그것이 필수적이기 때문입니다.

Legacy 를 이전하더라도, 기능단위로 해당 로직을 완벽히 파악하고 테스트코드를 작성하고 이전한다면,
이전후에도 당연히 작성해야할 테스트코드를 작성하는데에 더 효율적이게됩니다.

저는 최근에 일평균 거래대금 100억원을 처리하는 기능을 Legacy 에서 이전하였는데요,
테스트코드는 저에게 완벽한 안전장치가 되어주었고, 성공적으로 JiraTicket 을 해결할 수 있었습니다.

사실, 실제 운영되고 있는 서비스가 아닌 개인프로젝트를 할 때에는 이 의미를 저는 잘 몰랐습니다.

하지만, 실제로 운영되고 있는 서비스이고, 해당 기능으로 인해 거래대금 100억원이 문제가 생길 수 있다는 것을 인지한다면,
그리고 테스트코드가 우리의 실수를 방지해주는 안전장치임을 느끼는 순간 온몸에 전율이 돋을 것 입니다.

테스트코드의 의미를 다시한번 생각해보면 좋을 듯 합니다.

끝으로, 저에게 고민의 방향을 제시해주신 팀내 시니어분께 감사를 전하며
이만 글을 마칩니다.

반응형