백엔드·

마켓컬리 Hello World·2020년

BDD로 테스트에 중독되어 보자

팀 기술 모임에서 BDD를 접한 뒤 적립금 만료일 계산기를 예제로 테스트 표현을 다듬은 짧은 실험기다. 한 번에 테스트 하나만 작성하고, 페어 프로그래밍으로 시작한 결과를 Pull Request와 팀 리뷰를 통해 읽기 쉬운 계층형 시나리오로 개선했다. BDD의 도구보다 정책을 자연어로 정확히 표현하는 능력이 중요하다는 결론을 남긴다.

핵심 포인트

BDD의 계층형 테스트 결과가 기능 정책을 읽기 좋게 보여준다는 점에서 실험을 시작했다.
테스트 대상은 지급일 기준 다음 해 분기 말일, 다음 해 같은 날, N일 후라는 세 가지 적립금 만료 정책이었다.
한 번에 하나의 테스트만 작성하는 규칙으로 사례와 기대 결과를 작게 검증했다.
첫 결과는 계층 구조가 있어도 문장이 어색해 의도가 잘 읽히지 않았다.
페어 작업 뒤 PR과 팀 리뷰를 거쳐 정책 문장을 더 명확하게 다듬었다.

상세 정리

도입: 매주 기술 이야기를 나누는 자리에서 사내 위키의 BDD 정리와 계층형 테스트 결과 화면을 접했다.
첫 적용: BDD 경험자와 페어로 단순한 기능부터 테스트를 작성했다.
정책 1: 지급일의 다음 해에서 같은 날짜가 속한 분기의 마지막 날을 만료일로 계산한다.
사례: 2020년 1월 1일 지급분은 2021년 3월 31일, 2020년 4월 1일 지급분은 2021년 6월 30일이 된다.
정책 2·3: 다음 해 같은 날짜, 또는 지급일로부터 N일 뒤를 각각 만료일로 계산한다.
작성 규율: 여러 경우를 한 번에 만들지 않고 테스트 하나를 작성해 통과시킨 뒤 다음 사례로 넘어갔다.
첫 피드백: 결과가 계층형이지만 영문과 문장 구성이 섞여 정책을 빠르게 이해하기 어려웠다.
개선: Pull Request에서 더 많은 팀원의 의견을 받고 테스트 설명을 자연스러운 한국어 시나리오로 다듬었다.
결론: BDD는 테스트 출력 형식만의 문제가 아니다. 도메인 규칙을 정확한 문장과 사례로 표현할 때 읽기 좋은 명세가 된다.

왜 읽나작은 날짜 정책을 BDD로 옮기며 테스트 이름과 시나리오 문장을 팀 리뷰로 개선하는 가벼운 시작점을 찾는 개발자에게 맞는다.

마켓컬리 Hello World 블로그

원문은 여기서 이어서 읽을 수 있어요

읽음 (0)

·takedown 요청

이 글과 비슷한