지속 가능한 인수 테스트 주도 개발
- 시간: 14:55-15:35
- 발표자: 류성현(테크코스교육개발실/서버교육팀)
최근 Spring 3로 구성되어있는 동아리 프로젝트를 SpringBoot로 마이그레이션하는 기획, 실행을 담당(자처)했다.
로컬 환경설정, 배포과정의 복잡성 등의 다양한 이유로 새로운 SpringBoot 프로젝트로 리빌딩을 수행하려고 한다.
이 과정에서 기존 코드에 테스트가 한줄도 없기 때문에 마이그레이션이 정상적으로 완료되었는지를 판별할 수 있는 무언가가 필요했다.
이 과정에 ATDD 방식을 적용해보면 좋겠다는 생각에 해당 세션을 듣게 되었다.
인수테스트 주도 개발이란?
시스템이 인수기준을 만족시키는가와 고객이 시스템을 인수할 것인가를 결정할 수 있도록 행하는 형식 검사를 의미한다.
요구사항이나 기능의 완료 기준을 의미하는 인수테스트를 작성하며 개발을 진행할 수 있다.
점진적인 개선
ATDD라는 프로세스를 도입하기 전 팀원들에게 필요성에 대한 공감대를 먼저 형성해야한다.
발표자는 다음과 같은 경험을 통해 인수테스트의 필요성을 느꼈다.
- 제공하는 기능 및 시나리오 파악
- 전반적인 흐름을 쉽게 이해
- 세부적인 스펙 확인도 가능
처음에는 API 레벨의 E2E 테스트와 테스트 Fixture 관리라는 두가지의 간단한 규칙만을 가지고 ATDD를 적용하고 수행했다.
초기의 규칙이라 많이 불안정하다고 느낄 수도 있지만 생각보다 이로인한 문제점은 늦게 찾아오기 때문에 초기에 많은 리소스를 들이는 것이 필수는 아니다.
그렇다면 언제 개선해야할까?
정기적인 개발 회의 혹은 코드리뷰 과정을 통해 점진적으로 개선할 수 있다.
또는 실제로 문제가 발생했을 때 이를 해결하면 된다.
기록
인수테스트 도입과정에서 작성되는 내용들은 정답이 있는 내용이 아니기 때문에 많은 논의가 필요하다.
예를들어 한글 메서드 명을 사용한다, 중복되는 RestAssured 요청을 Fixture로 분리한다 등과 같은 내용들이 있을 것이다.
이러한 과정을 잘 기록해두고 추후 다른 개발자들이 이러한 문제상황 혹은 컨벤션에 익숙해질 수 있도록 도와줘야한다.
인수테스트 정책 논의과정, 인수테스트 작성 가이드 등을 wiki에 작성하면 좋다.
개선 사례
기능이 늘어나고 인수테스트가 늘어날 수록 테스트의 복잡성도 함께 증가하기 마련이다.
중복을 제거하기 위한 Fixture코드조차 중복이 일어나고, 관리 난이도도 높아진다.
이러한 문제점은 인수테스트 작성에 피로감을 느끼게 하고, 잘 굴러가는 기능이라면 필요성조차 느끼지 못하게 될 수도 있다.
이에 인수테스트를 쉽게 만들 수 있는 방법으로 Cucumber를 도입해볼 수 있다.
Cucumber 활용
Feature: Is it Friday yet?
Everybody wants to know when it's Friday
Scenario: Sunday isn't Friday
Given today is Sunday
When I ask whether it's Friday yet
Then I should be told "Nope"Cucumber는 위와 같이 문장으로서 테스트 인터페이스를 구성할 수 있는 도구다.
이를 통해 테스트의 흐름을 일목 요연하게 확인할 수 있다는 장점이 있다.
이를 도입하고 회고를 거친 결과 다음과 같은 긍정적인 의견이 나왔다.
- 인수 테스트의 목적이 명확해짐
- 코드 재사용으로 인한 편한함
하지만 아직 해결해야할 과제는 남아있다.
- 러닝커브 및 초기 설정 리소스
- 컨벤션으로 커버되지 않는 케이스는 어떻게 처리?
- 인수 조건은 어떻게 도출?
인수 조건
사용자 스토리를 도출한다.
수강생으로서,
다음 미션에 피드백을 바로 반영하기 위해
미션이 끝나면 바로 피드백을 확인을 한다.이후 완료 조건을 도출한다.
- 수강생이 직접 피드백을 조회할 수 있다
- 피드백이 안 남겨져 있을 땐?
- 피드백 목록을 모아볼 수 있다이 완료조건을 기준으로 시나리오를 도출한다.
[ "수강생이 직접 피드백을 조회할 수 있다"에 대한 시나리오 ]
Given 강사가 강의를 생성한다
...
And 미션을 진행한다.
...
When 피드백을 조회를 요청한다.
Then 피드백을 조회할 수 있다.사용자 스토리
신규 인원의 서비스 파악의 이해를 돕기 위해 사용자 스토리 도출 활동을 진행할 수 있다.
이를 통해 다음과 같은 결과를 기대할 수 있다.
- 서비스에 대한 공통의 이해
- 시스템 히스토리 이해
- 개선 사항 도출 및 기능 개선
💡 활동 Tip
- 그라운드 룰을 정의해야한다.
- 왜 하는것이고
- 무엇을 하는 것이고
- 어떤 결과를 기대하는지에 대한 이해를 해야한다.
- 질문
- 반복되는 질문은 FAQ로 기록해둔다.
- 시간관리
- 루즈해지지 않도록 시간관리를 잘 해야한다.
- 형식에 매몰되지 않는것이 중요하다.
결론
지속 가능한 개발문화를 위해서는 다음과 같은 점들을 유의하면 좋다.
- 문화에 대한 필요성과 공감
- 지속적인 리뷰와 피드백
- 처움부터 완벽하지 않아도 된다.
후기
나 혼자 중요성을 알기 보다는 구성원들에게 해당 문제점을 인지시키고 이해와 공감을 얻어내는 것이 중요할 것 같다.
처음부터 완벽한 테스트와 문화를 만들기 보다는 일단 최소한의 규칙으로 시작해봐야겠다.
Reference
