Cucumber로 API와 데이터 정합성 검증하는 방법
안녕하세요, 에이슬립에서 B2B SaaS Product 품질을 리드 중인 지원입니다.
과거 행위주도개발(BDD) 프레임워크인 Cucumber와 Axios 라이브러리를 활용하여 API 기능 검증과 데이터 정합성 검증 환경을 구성했던 사례를 공유드리고자 합니다.
Cucumber Step Definitions(Given When Then)
우선 수많은 테스트 케이스를 효율적으로 관리하고 효과적으로 검증하기 위해서는 Cucumber의 Step Definitions(Given, When, Then)에 대한 이해가 필요한데요.
Step Definitions은 하나 이상의 Gherkin 단계에 연결하는 표현식이 존재하는 함수입니다. Cucumber가 시나리오에서 Gherkin 단계를 실행할 때 일치하는 Step Definitions를 찾는 과정을 통해 테스트 코드가 실행되는 방식입니다.
예를 들어 Feature 파일에 위와 같은 Step Definitions(Given)이 존재할 경우 Step Definitions 파일에 위에서 정의된 Data API Base URL 초기화 정규 표현식 또는 Cucumber 표현식이 존재해야 합니다.
그리고 표현식을 활용하여 위와 같이 테스트 시나리오마다 필요한 패스 파라미터를 테스트 필요한 값으로 유연하게 구성하여 API 요청을 할 수 있습니다.
위와 같은 구조를 보다 잘 활용하기 위해서는 몇 가지 구성이 필요한데요. API 검증 구조를 전체적으로 어떻게 구성해야 하는지 살펴보겠습니다.
API 클래스 구성
API 호출을 단순화하고 재사용 가능한 메서드를 제공하여 코드를 간결하게 유지하도록 API 클래스를 구성한 모습인데요.
클래스의 생성자를 통해 필요한 정보(apiKey, userId)를 전달받아 인스턴스 변수로 저장합니다. 이로써 클래스의 인스턴스가 만들어질 때마다 필요한 정보가 설정되어 별도로 헤더를 구성할 필요가 없습니다.
또한 생성자에서 optional 하게 전달된 timezone 을 고려하여 헤더를 동적으로 설정합니다.
그리고 모든 API 호출에서 validateStatus 옵션을 통해 서버가 반환하는 모든 상태 코드에 대한 처리를 각 요청별로 유연하게 구성할 수 있습니다.
Base 클래스 구성
API 기능 검증과 전체 데이터에 대한 정합성 검증을 위해서는 테스트 필요한 데이터를 다음 시나리오에서 활용할 수 있도록 구성이 필요한데요. 특히 특정 조건에 존재하는 모든 데이터에 대한 검증을 진행하려면 원하는 조건의 데이터를 배열에 담고 활용해야 하므로 위와 같이 데이터를 설정하고 반환할 수 있도록 구현이 필요합니다.
테스트 로직 구성
위 로직은 특정 엔드포인트에 GET 요청을 보내고, 응답으로 받은 세션 리스트에서 특정 조건을 만족하는 세션들의 ID를 추출하여 base 객체의 setSessionIDs 메서드를 통해 저장하는 로직인데요.
이렇게 함으로써 여러 테스트 간에 데이터의 일관성과 정합성을 유지한 채 테스트를 구성할 수 있고, 저장된 세션 ID를 다른 테스트에 활용(패스 파라미터, 로깅 등)하여 해당 세션들에 대한 다양한 테스트를 요구사항에 맞춰서 수행할 수 있습니다.
테스트 커버리지 확장
Cucumber에서는 한번 만들어진 Step Definitions(Given, When, Then)을 활용하면 테스트 시나리오를 위와 같이 자연어로 작성하면서 커버리지를 확장할 수 있고 테스트 결과 분석 및 디버깅 간에도 어떤 테스트 로직에서 실패가 발생했는지 보다 명확하게 파악할 수 있습니다.
마치며
지금까지 BDD 프레임워크인 Cucumber를 활용하여 백엔드 API를 검증하는 방법에 대해서 살펴보았습니다.
현재는 에이슬립 B2B SaaS Product의 웹과 API 품질에 한해서만 대규모 테스트 케이스를 검증하는 과정에서 자동화 운영 측면에서 예상되는 비효율적인 상황들을 예방하고자 Microsoft에서 개발한 오픈소스 자동화 라이브러리인 Playwright로 전체 마이그레이션을 진행 중에 있어서 더 이상 Cucumber를 활용하지 않을 것 같지만
과거 B2C 모바일 프로덕트 자동화를 리드할 당시 Python과 Java 기반으로 Cucumber를 활용해 보면서 느꼈던 장점들로 인해서 최근까지 Cucumber를 CICD 파이프라인에서 배포 전후 검증에 사용하게 되었는데요.
다양한 프레임워크와 테스트 방법론을 접하면서 느낀 건 트레이드오프(trade-off)가 항상 존재하기에 모든 상황에 적합한 방법은 없었고 현재 팀과 개발 문화에 적합한 방식이 보다 더 나은 선택의 의사결정 기준이 되는 것 같습니다.
감사합니다.
