행동 주도 개발(Behavior-Driven Development)은 테스트를 모두가 읽을 수 있도록 만들어 소프트웨어 품질에 대한 팀의 생각을 근본적으로 변화시켰습니다! BDD 테스트에 Cucumber를 사용하는 것은 비즈니스 요구사항과 기술 구현 사이의 간극을 메우고, 실제로 실행되는 살아있는 문서를 생성하는 기술입니다. 작성되는 순간부터 쓸모없어지는 테스트 케이스로 어려움을 겪었다면, 이 가이드가 더 나은 방법을 보여줄 것입니다.
Cucumber와 BDD는 무엇인가요?
Cucumber는 일반 언어로 작성된 자동화된 테스트를 실행하는 오픈 소스 도구입니다. 이는 개발자, 테스터, 비즈니스 이해관계자가 구체적인 예시를 사용하여 소프트웨어 동작을 정의하도록 협력하는 방법론인 행동 주도 개발(BDD)을 구현합니다.
BDD는 "어떻게 테스트해야 하는가?" 보다는 "시스템이 무엇을 해야 하는가?"라는 한 가지 질문에 답하는 데 중점을 둡니다. 그 결과 오해를 없애고 명세서이자 실행 가능한 유효성 검사 역할을 하는 공통 언어가 탄생합니다.
Cucumber는 Gherkin 구문으로 작성된 시나리오가 포함된 .feature 파일을 읽고, 실제 자동화를 수행하는 코드인 스텝 정의(step definitions)에 대해 이를 실행합니다. 이러한 분리를 통해 비즈니스 이해관계자는 코드를 읽지 않고도 테스트 시나리오를 검토할 수 있으며, 개발자는 기술적 세부 사항을 별도로 구현할 수 있습니다.
JavaScript용 Cucumber 설치하기
Node.js 프로젝트에 Cucumber를 설정하는 데는 몇 가지 명령어만 필요합니다.
전제 조건:
- Node js
- NPM
- 로그인 기능이 있는 API 프로젝트 (이 튜토리얼은 Cucumber 설치 및 Gherkin 테스트만 다룹니다).
# Create a new project directory
mkdir cucumber-bdd-demo && cd cucumber-bdd-demo
# Initialize npm
npm init -y
# Install Cucumber and testing dependencies
npm install --save-dev @cucumber/cucumber chai axios
package.json 파일에 다음 테스트 스크립트가 포함되어야 합니다:
{
"scripts": {
"test": "cucumber-js"
}
}
다음 디렉토리 구조를 생성하세요:
project/
├── features/
│ └── user-management.feature
├── step-definitions/
│ └── user-steps.js
├── package.json
└── cucumber.json
실용 가이드: 첫 BDD 테스트 작성하기
실제로 BDD 테스트에 Cucumber를 효과적으로 사용하는 방법을 보여주기 위해 사용자 관리 API에 대한 테스트를 구축해 봅시다.
1단계: 피처 파일 작성
features/user-management.feature 파일을 생성합니다:
Feature: 사용자 관리 API
API 클라이언트로서
사용자를 관리하고 싶다
내 애플리케이션에 사용자 기능을 통합할 수 있도록
Scenario: 새 사용자 성공적으로 생성
Given 유효한 사용자 페이로드가 있다
When "/api/users"로 POST 요청을 보낸다
Then 응답 상태는 201이어야 한다
And 응답에 사용자 ID가 포함되어야 한다
Scenario: 유효하지 않은 이메일로 사용자 생성 시도
Given 유효하지 않은 이메일을 가진 사용자 페이로드가 있다
When "/api/users"로 POST 요청을 보낸다
Then 응답 상태는 400이어야 한다
And 응답에 "Invalid email format"이 포함되어야 한다
2단계: 스텝 정의 구현
step-definitions/user-steps.js 파일을 생성합니다:
const { Given, When, Then } = require('@cucumber/cucumber');
const { expect } = require('chai');
const axios = require('axios');
let requestPayload;
let response;
Given('I have a valid user payload', function() {
requestPayload = {
name: 'Test User',
email: 'test@example.com',
password: 'ValidPass123'
};
});
Given('I have a user payload with invalid email', function() {
requestPayload = {
name: 'Test User',
email: 'invalid-email',
password: 'ValidPass123'
};
});
When('I send a POST request to {string}', async function(endpoint) {
try {
response = await axios.post(`http://localhost:3000${endpoint}`, requestPayload);
} catch (error) {
response = error.response;
}
});
Then('the response status should be {int}', function(statusCode) {
expect(response.status).to.equal(statusCode);
});
Then('the response should contain a user ID', function() {
expect(response.data).to.have.property('userId');
expect(response.data.userId).to.match(/^[0-9a-fA-F]{24}$/);
});
Then('the response should contain {string}', function(message) {
expect(response.data.message).to.include(message);
});
3단계: Cucumber.json 파일 편집
프로젝트의 루트 디렉토리에 "cucumber.json" 파일을 생성하고 다음 코드를 추가합니다:
{
"default": {
"formatOptions": {
"snippetInterface": "synchronous"
}
}
}4단계: 테스트 실행
다음 명령어로 테스트를 실행합니다:
npm test
Cucumber는 어떤 스텝이 통과했는지, 정의되지 않았는지 또는 실패했는지 보여주는 자세한 결과를 출력할 것입니다.
좋은 BDD 시나리오 작성 규칙
BDD 테스트에 Cucumber를 효과적으로 사용하는 방법을 배우려면 다음과 같은 검증된 규칙을 따라야 합니다:
1. Given-When-Then 구조
모든 시나리오는 다음 세 부분을 순서대로 포함해야 합니다:
- Given: 전제 조건 설정
- When: 동작 설명
- Then: 결과 유효성 검증
2. 선언적으로 작성하고 명령적으로 작성하지 마세요
나쁜 예:
Given 브라우저를 연다
And "/login"으로 이동한다
And 이메일 필드에 "test@example.com"을 입력한다
And 비밀번호 필드에 "password"를 입력한다
And 로그인 버튼을 클릭한다
좋은 예:
Given 로그인 페이지에 있다
When 유효한 자격 증명으로 로그인한다
Then 대시보드를 볼 수 있어야 한다
어떻게 하는지가 아니라 무엇을 테스트하는지에 집중하세요.
3. 하나의 시나리오, 하나의 목적
각 시나리오는 단일 동작을 테스트해야 합니다. 시나리오를 결합하면 실패를 숨기고 디버깅을 어렵게 만듭니다.
4. 비즈니스 언어 사용
비즈니스 이해관계자가 이해할 수 있는 시나리오를 작성하세요. 기술 용어와 구현 세부 사항은 피하세요.
5. 시나리오 독립적으로 만들기
시나리오는 서로 의존해서는 안 됩니다. 각 시나리오는 자체 데이터를 설정하고 나중에 정리해야 합니다.
고급 Cucumber 기능: 데이터 테이블 및 시나리오 아웃라인
복잡한 입력을 위한 데이터 테이블
여러 데이터 포인트로 테스트해야 할 경우 테이블을 사용합니다:
Scenario: 다른 역할의 사용자 생성
Given 다음 사용자 데이터가 있다:
| name | email | role |
| Alice | alice@example.com | admin |
| Bob | bob@example.com | user |
When "/api/users"로 POST 요청을 보낸다
Then 모든 사용자가 성공적으로 생성되어야 한다
스텝 정의:
Given('I have the following user data:', function(dataTable) {
requestPayload = dataTable.hashes();
});
데이터 기반 테스트를 위한 시나리오 아웃라인
다른 데이터로 동일한 시나리오를 실행하려면 아웃라인을 사용합니다:
Scenario Outline: 다양한 자격 증명으로 로그인
Given 로그인 페이지에 있다
When ""과 ""를 입력한다
Then ""를 볼 수 있어야 한다
Examples:
| email | password | result |
| test@example.com | validPass | Dashboard |
| test@example.com | wrongPass | Invalid password|
| invalid@email.com | validPass | Invalid email |
이렇게 하면 세 가지 개별 테스트 시나리오가 자동으로 생성됩니다.
태그로 테스트 구성하기
태그는 시나리오를 분류하고 필터링하는 데 도움이 됩니다:
@smoke @regression
Scenario: 사용자 로그인
Given 로그인 페이지에 있다
When 유효한 자격 증명으로 로그인한다
Then 대시보드를 볼 수 있어야 한다
@api @critical
Scenario: API 상태 확인
Given API가 실행 중이다
When "/health"로 요청한다
Then 응답 상태는 200이어야 한다
특정 태그만 실행:
npm test -- --tags "@smoke"
Apidog가 BDD 워크플로우에서 API 테스팅을 돕는 방법
Cucumber가 동작 정의에 탁월한 반면, Apidog는 API 테스트 생성 및 실행의 번거로운 작업을 자동화하여 BDD 테스팅을 위한 Cucumber를 훨씬 더 효율적으로 만듭니다.
AI 기반 API 테스트 케이스 생성
API 호출에 대한 스텝 정의를 수동으로 작성하는 대신, Apidog는 AI를 사용하여 OpenAPI 명세에서 이를 생성합니다:
# Your API spec
paths:
/api/users:
post:
requestBody:
content:
application/json:
schema:
type: object
properties:
name: string
email: string
responses:
'201':
description: User created
Apidog는 테스트 준비된 시나리오를 자동으로 생성합니다:
- 긍정 테스트: 유효한 페이로드 → 201 상태
- 부정 테스트: 유효하지 않은 이메일 → 400 상태
- 경계 테스트: 필수 필드 누락 → 400 상태
자주 묻는 질문
Q1: Cucumber 테스트를 작성하려면 프로그래밍을 알아야 하나요?
답변: Gherkin 시나리오를 작성하는 데는 코딩이 필요하지 않습니다. 행동에 대한 명확한 사고만 있으면 됩니다. 그러나 스텝 정의를 구현하려면 JavaScript(또는 다른 언어) 지식이 필요합니다. Apidog와 같은 도구는 스텝 정의 코드를 자동으로 생성하여 이러한 부담을 줄여줍니다.
Q2: Cucumber는 기존 테스팅 프레임워크와 어떻게 다른가요?
답변: 기존 프레임워크(Jest, Mocha)는 기술 구현에 중점을 둡니다. Cucumber는 비즈니스 행동에 중점을 둡니다. 동일한 Cucumber 시나리오는 Gherkin 텍스트를 변경하지 않고 웹 UI 테스트(Selenium), API 테스트(Axios) 또는 모바일 테스트(Appium)를 구동할 수 있습니다.
Q3: Cucumber가 API 테스팅 도구를 대체할 수 있나요?
답변: Cucumber는 테스트 구조를 제공하지만, API 호출(Axios, Supertest)을 실행하고 응답을 검증하는 도구는 여전히 필요합니다. Apidog는 Cucumber가 BDD 워크플로우를 관리하는 동안 API 실행 계층을 처리하여 Cucumber를 보완합니다.
Q4: 좋은 Cucumber 시나리오는 무엇인가요?
답변: 좋은 시나리오는 독립적이며, 비즈니스 언어를 사용하고, Given-When-Then 구조를 따르며, 각각 하나의 동작을 테스트합니다. 비기술적 이해관계자가 읽을 수 있어야 하며, 시스템이 "무엇"을 하는지에 초점을 맞추고 "어떻게" 하는지는 중요하지 않습니다.
Q5: Apidog는 BDD 테스트에서 인증을 어떻게 처리하나요?
답변: Apidog는 인증 토큰을 자동으로 관리합니다. Apidog의 자격 증명 관리 기능을 사용하여 유효한 토큰을 검색하는 "Given I am authenticated" 스텝을 정의할 수 있으므로, 스텝 정의에서 수동 토큰 처리가 필요 없습니다.
결론
BDD 테스트에 Cucumber를 사용하는 것은 기술 및 비즈니스 팀 간의 공유된 이해를 형성하여 개발 프로세스를 효과적으로 변화시킵니다. Gherkin 구문은 명확성을 강제하고, 시나리오와 스텝 정의의 분리는 애플리케이션이 발전함에 따라 테스트를 유지 관리할 수 있게 합니다.
진정한 힘은 Cucumber를 최신 자동화 도구와 통합하는 것에서 나옵니다. Apidog는 API 테스트 코드를 작성하는 지루한 수동 작업을 없애고, 실행을 처리하는 동안 의미 있는 동작을 정의하는 데 집중할 수 있도록 합니다. 이 조합은 양쪽의 장점을 모두 제공합니다: 살아있는 문서 역할을 하는 사람이 읽을 수 있는 명세서, 그리고 지속적으로 실행되는 강력한 자동화된 테스트.
작게 시작하세요. 하나의 API 엔드포인트를 선택하고, 성공, 실패, 엣지 케이스 세 가지 시나리오를 작성하세요. 스텝 정의를 구현하고 실행하세요. 결과를 제품 소유자에게 보여주세요. 그들이 비즈니스 요구사항이 테스트로 실행되는 것을 보게 되면, 전체 프로젝트에 BDD를 확장할 수 있는 동의를 얻게 될 것입니다. 바로 그때 BDD 테스트에 Cucumber를 사용하는 것이 기술적인 관행을 넘어 팀 전체의 품질 운동이 됩니다.