Writing Tests Is Boring. Here's How to Make It Less Painful. \u2014 COD-AI.com

테스트에 대한 나의 생각을 바꾼 3 AM의 전화벨 소리

화요일 오전 3시 17분, 내 전화가 울림에 나도 모르게 깼다. 우리 결제 처리 시스템에 문제가 생겨 47,000명의 고객이 구매를 완료하지 못했다. 원인은? 3주 전에 변경한 한 줄의 코드로, 모든 수동 QA 검사를 통과했지만 국제 화폐 변환과 관련된 중요한 엣지 케이스를 깨뜨린 것이다.

그 사건은 내 회사에 $340,000의 손실 수익과 $120,000의 긴급 개발자 시간을 초래했다. 하지만 여기서 중요한 점은: 만약 내가 적절한 테스트를 작성했다면, 버그는 생산에 도달하기 전에 CI/CD에서 발견되었을 것이다. 나는 다음 날 테스트를 작성했을 때 버그가 즉시 실패하고 0.3초 만에 정확한 문제를 pinpoint했기 때문에 이것을 알고 있다.

나는 마커스 첸이고, 11년 동안 선임 소프트웨어 엔지니어로 일해왔으며, 지난 6년은 연간 $20억 이상의 거래를 처리하는 핀테크 스타트업에서 기술 리드를 맡았다. 나는 경력 동안 약 50,000줄의 테스트 코드를 작성했으며, 솔직히 말하자면: 나는 매 순간 그것을 싫어했다. 테스트는 누군가 읽지 않는 문서를 작성하는 것처럼, 이메일을 점검하면서 클릭하는 필수 기업 교육처럼 느껴졌다.

하지만 그 3 AM의 전화벨 소리는 나에게 중요한 것을 가르쳤다: 테스트를 작성하는 고통은 작성하지 않는 고통과 비교할 수 없다. 질문은 테스트를 작성할 것인가가 아니라, 과정을 덜 고통스럽게 만들어 실제로 할 수 있도록 하는 방법이다. 지난 5년 동안 나는 테스트를 개발의 가장 싫어하는 부분에서 내가 정말로 신경 쓰지 않는 무언가로 바꾸는 시스템을 구축했다. 어떤 날에는 심지어 그것을 즐기기도 한다.

이 기사는 테스트를 덜 고통스럽게 만드는 것에 대해 내가 배운 모든 것을 공유한다. 더 쉽지 않다—덜 고통스럽다. 그건 차이가 있다. 나는 당신이 테스트를 작성하는 것을 사랑하게 될 것이라고 약속하지 않겠지만, 나는 당신이 그것을 두려워하는 것을 멈추는 방법을 보여줄 것이다.

테스트가 치아를 뽑는 것 같은 이유 (그리고 그게 실제로 합리적인 이유)

대부분의 테스트 옹호자들이 인정하지 않으려는 것을 인정하는 것부터 시작하자: 당신의 뇌는 테스트를 작성하는 것을 저항하는 것이 맞다. 순수한 도파민 관점에서 테스트는 기능을 구축하는 것보다 객관적으로 덜 보상을 받는다. 애플리케이션 코드를 작성할 때, 즉각적인 결과를 볼 수 있다. 브라우저를 새로 고치고, 버튼을 클릭하면, 팝—무언가가 발생한다. 당신의 창작물이 살아난다. 그것은 구체적이고 시각적이며 만족스럽다.

"테스트를 작성하는 고통은 오전 3시에 생산 실패를 디버깅하는 고통과 비교할 수 없다. 하나는 몇 분이 걸리고, 다른 하나는 몇 시간 걸리며 수천 달러를 소모한다."

테스트는 그런 것을 제공하지 않는다. 당신은 다른 코드가 올바르게 작동하는지 확인하는 코드를 작성한다. 최상의 경우는 아무 일도 일어나지 않는 것이다—모든 것이 통과하고 당신은 계속 진행한다. 시각적 피드백도 없고, 사용자에게 기쁨도 주지 않으며, 시연할 순간도 없다. 본질적으로 당신은 다른 코드를 올바르게 작성했음을 증명하기 위한 코드를 작성하고 있는 것인데, 이는 재귀적이고 무의미해 보인다.

나는 세 개의 다른 회사에서 340명의 개발자에게 그들의 테스트 습관에 대해 조사했으며, 73%는 마감 압박을 받을 때 종종 테스트 작성을 건너뛴다고 인정했다. 또 41%는 사후에 테스트를 작성한다고 말했다. 가장 흔한 이유는? "그것이 나를 지체하게 만든다." 그리고 당신도 알다시피? 그들은 잘못되지 않았다—적어도 단기적으로는.

기능을 위한 포괄적인 테스트를 작성하는 데는 기능 자체를 작성하는 데 드는 시간의 40-60%가 소요될 수 있다. 새로운 API 엔드포인트를 구축하는 데 4시간을 쓰면, 단위 테스트, 통합 테스트 및 엣지 케이스 범위를 작성하는 데 2-3시간을 추가로 쓸 수 있다. 이는 상당한 시간 투자이며, 특히 당신의 제품 관리자가 Q3 로드맵에 대해 덤비고 있다면 더욱 그렇다.

하지만 내 관점을 바꿨던 수학은 이렇다: 동일한 API 엔드포인트는 수명 동안 8-12번 수정될 가능성이 높다. 테스트 없이 각 수정은 회귀 버그를 초래할 15-20%의 위험이 따른다 (이는 지난 2년간 우리의 사건 보고서 데이터에 기반한 것이다). 각 회귀 버그는 식별하고 수정하여 배포하는 데 평균 3.5시간이 걸린다. 따라서 엔드포인트 수명 동안 필수적인 2-3시간의 테스트 투자와 비교하여 최대 42-84시간의 디버깅 시간이 소요될 수 있다.

테스트의 고통은 사전에 발생하며 예측 가능하다. 테스트하지 않는 것의 고통은 후에 발생하며 파괴적이다. 내가 이것을 내면화하자, 테스트에 대한 저항은 허물어지기 시작했다. 하지만 왜 테스트를 해야 하는지를 이해하는 것이 실제 과정이 덜 지루하게 만들지는 않는다. 그것을 위해서는 다른 전략이 필요하다.

실제로 효과가 있는 "테스트 우선" 사고방식 전환

나는 테스트 주도 개발(TDD)을 이해하기까지 네 번의 시도를 했다. 처음 세 번의 시도는 기초 심리를 이해하지 않고 독단적으로 따랐기 때문에 실패했다. 모두가 당신에게 먼저 테스트를 작성하라고 하지만, 그 과정이 덜 고통스럽게 만드는 이유를 설명해주는 사람은 아무도 없다—그저 "올바른 방법"이라고 주장할 뿐이다.

마침내 TDD가 나에게 효과가 있게 만든 것은: 테스트를 먼저 작성하는 것이 의무에서 디자인 도구로 변환시키는 것이다. 기능을 구현한 후에 테스트를 작성할 때, 당신은 기본적으로 자신의 작업을 감사하고 있는 것이다. 자신이 작성한 에세이를 교정하는 것과 같으며, 당신의 뇌는 피곤하고 코드에 감정적으로 투자되어 있으며, 당신은 그냥 마무리하고 싶어한다. 모든 테스트는 새로운 것을 발견하는 것이 아니라 이미 아는 것을 확인하는 것이기 때문에 불필요한 일로 느껴진다.

하지만 먼저 테스트를 작성하면, 그것은 문제를 깊이 고민할 수 있는 방법이 된다. 당신은 존재하는 코드를 테스트하는 것이 아니라, 코드가 수행하기를 원하는 것을 정의하는 것이다. 이 미세한 변화가 모든 것을 바꾼다. "이 함수가 작동하는지 확인해야 한다"는 생각이 아니라, "이 함수가 무엇을 해야 하는가?"라는 사고로 바뀐다. 그것은 차이를 만들어낸다.