DEV Community

Cover image for Apidog을 활용한 API 테스트 데이터베이스 쿼리 사용법 (MySQL, MongoDB, Redis)
Rihpig
Rihpig

Posted on • Originally published at apidog.com

Apidog을 활용한 API 테스트 데이터베이스 쿼리 사용법 (MySQL, MongoDB, Redis)

초록색 상태 코드는 거짓말을 할 수 있습니다. POST /orders가 201 Created를 반환하고 응답 본문과 테스트가 모두 정상이어도, 주문 행이 올바른 상태로 실제 데이터베이스에 저장됐는지는 별개의 문제입니다. 재고가 감소했는지, 외래 키가 유효한지, 소프트 삭제가 의도치 않게 하드 삭제로 처리되지는 않았는지 확인하려면 HTTP 응답이 아니라 데이터베이스를 직접 검증해야 합니다.

지금 Apidog 사용해 보기

테스트 시나리오에 데이터베이스 쿼리를 넣으면 요청 전 상태를 시드하고, API 호출 후 실제 저장된 데이터를 읽어 검증할 수 있습니다. Apidog는 데이터베이스 연결(Database Connections)과 데이터베이스 작업(Database Operation) 프로세서를 제공하므로, 외부 스크립트 없이 HTTP 요청과 SQL 또는 NoSQL 작업을 하나의 시나리오에서 실행할 수 있습니다. 요청 수준의 시나리오 작성 방법은 Apidog로 테스트 시나리오를 작성하는 방법을 참고하세요. 관계형 데이터 모델의 기본 개념은 MDN의 서버 측 개요에서 복습할 수 있습니다.

테스트 내 데이터베이스 작업이 필요한 이유

HTTP 응답만 검증하는 테스트는 블랙박스 테스트입니다. API가 반환한 값을 신뢰하지만, 실제 버그는 종종 응답과 영속 데이터 사이에서 발생합니다.

데이터베이스 작업을 추가하면 다음을 수행할 수 있습니다.

  • 테스트 시작 상태를 시드해 기존 데이터에 의존하지 않기
  • API가 작성한 행을 직접 읽어 실제 데이터 검증하기
  • 데이터베이스 값을 변수로 추출해 다음 요청에 전달하기

Apidog에서는 다음 순서로 구성합니다.

  1. Settings > Database Connections에서 재사용할 데이터베이스 연결을 만듭니다.
  2. 요청의 Pre Processor에 데이터베이스 작업을 추가해 데이터를 시드합니다.
  3. 요청의 Post Processor에 데이터베이스 작업을 추가해 저장 결과를 검증합니다.

MySQL, SQL Server(2014 이상), PostgreSQL, Oracle은 무료 플랜에서 사용할 수 있습니다. ClickHouse, MongoDB, Redis는 유료 플랜이 필요합니다.

단계 1: 데이터베이스 연결 생성

Settings > Database Connections를 열고 오른쪽 상단의 + New를 클릭합니다. 데이터베이스 유형을 선택한 뒤 다음 정보를 입력합니다.

  • Host: 예: db.staging.internal, 127.0.0.1
  • Port: MySQL 기본값은 3306
  • Username, Password
  • Database Name: 예: shop

Apidog 데이터베이스 연결 설정

배스천 호스트를 거쳐야 한다면 SSH Tunnel 섹션을 확장해 점프 호스트 정보를 추가합니다.

MySQL 연결에서는 SSL 모드를 선택할 수 있습니다.

  • Prefer: SSL을 시도하고 실패하면 폴백
  • Require
  • Verify CA
  • Verify Full

서버가 지원하는 가장 엄격한 옵션을 선택한 뒤 Save를 클릭합니다.

MySQL 8 인증 오류 처리

MySQL 8의 기본 caching_sha2_password 플러그인 때문에 연결이 실패할 수 있습니다. 인증 오류가 발생하면 테스트 계정을 mysql_native_password로 전환한 후 다시 연결합니다.

ALTER USER 'tester'@'%'
IDENTIFIED WITH mysql_native_password BY '...';
Enter fullscreen mode Exit fullscreen mode

플러그인 차이는 MySQL 참조 매뉴얼에서 확인할 수 있습니다.

데이터베이스 연결 자격 증명은 로컬에 저장되며 클라우드에 동기화되지 않습니다. 팀원은 각자 연결을 구성해야 합니다. 팀 설정 절차는 데이터베이스 연결 설정 공유를 참고하세요.

단계 2: 사전 프로세서로 테스트 데이터 시드

주문 생성 API를 테스트한다고 가정하겠습니다. 주문을 만들기 전에 활성 고객이 존재하도록 보장해야 테스트가 기존 테이블 데이터에 영향을 받지 않습니다.

요청에서 다음을 설정합니다.

  1. Pre Processors를 엽니다.
  2. Add Database Processor > Database operation을 선택합니다.
  3. 작업 이름을 seed customer로 지정합니다.
  4. MySQL 연결을 선택합니다.
  5. Enter SQL Command에 시드 SQL을 입력합니다. 
INSERT INTO customers (id, email, status)
VALUES ({{customer_id}}, '{{customer_email}}', 'active')
ON DUPLICATE KEY UPDATE status = 'active';
Enter fullscreen mode Exit fullscreen mode

{{customer_id}}, {{customer_email}}은 환경 변수나 시나리오 변수입니다. 이 방식으로 각 테스트는 다음 상태를 보장합니다.

  • 고객이 존재함
  • 고객 상태가 active임
  • 이후 단계에서 사용할 고객 ID가 명확함

단계 3: 사후 프로세서로 저장 데이터 검증

이제 주문 생성 요청을 실행합니다.

POST /api/orders
Content-Type: application/json

{
  "customer_id": {{customer_id}},
  "items": [{ "sku": "APRON-01", "qty": 2 }]
}
Enter fullscreen mode Exit fullscreen mode

응답 본문의 주문 ID를 일반 응답 단언으로 order_id 변수에 저장했다고 가정합니다. 그다음 같은 요청에 데이터베이스 사후 프로세서를 추가합니다.

  1. Post Processors를 엽니다.
    • DESIGN Mode에서는 Run 탭
    • DEBUG Mode에서는 Request 탭
  2. Add PostProcessor > Database operation을 선택합니다.
  3. 이름을 verify order row로 지정합니다.
  4. 데이터베이스 연결을 선택합니다.
  5. 다음 SQL을 실행합니다. 
SELECT id, status, total_cents
FROM orders
WHERE id = {{order_id}};
Enter fullscreen mode Exit fullscreen mode

쿼리 결과는 행 객체 배열로 반환됩니다. 첫 번째 행의 상태를 변수로 추출하려면 Extract Results (Optional)에서 Extract Result To Variable을 추가합니다.

  • Variable Name: db_order_status
  • JSONPath Expression: 
$[0].status
Enter fullscreen mode Exit fullscreen mode

이제 db_order_status를 기대값과 비교하는 단언을 추가합니다.

db_order_status == "pending"
Enter fullscreen mode Exit fullscreen mode

이 검증은 API가 201 Created를 반환했는지만 확인하는 것이 아닙니다. 실제 orders 테이블에 저장된 status 값이 기대한 값인지 확인합니다. 예를 들어 API가 성공 응답을 반환했지만 status = 'draft'를 저장했다면 테스트가 실패합니다.

단계 4: 데이터베이스 값을 다음 요청에 전달

데이터베이스에서 읽은 값은 검증 외에도 다음 요청의 입력값으로 사용할 수 있습니다.

예를 들어 주문 생성 시 서버가 내부 fulfillment_ref를 생성해 orders 테이블에 저장하지만, API 응답에는 이 값을 반환하지 않는다고 가정합니다. 다음 요청이 이 참조 값을 필요로 한다면 사후 프로세서에서 조회합니다.

SELECT fulfillment_ref
FROM orders
WHERE id = {{order_id}};
Enter fullscreen mode Exit fullscreen mode

결과 추출 설정은 다음과 같습니다.

  • Variable Name: fulfillment_ref
  • JSONPath Expression: 
$[0].fulfillment_ref
Enter fullscreen mode Exit fullscreen mode

다음 요청에서는 실제 서버가 생성한 값을 사용합니다.

GET /api/fulfillments/{{fulfillment_ref}}
Enter fullscreen mode Exit fullscreen mode

이는 HTTP 응답 값을 다음 단계로 전달하는 방식과 동일한 패턴입니다. 차이점은 데이터 원본이 JSON 응답이 아니라 데이터베이스라는 점입니다. 관련 패턴은 테스트 단계 간 데이터 전달 및 API 테스트 오케스트레이션 및 데이터 전달에서 확인할 수 있습니다.

MongoDB 및 Redis: NoSQL 작업

MongoDB와 Redis도 데이터베이스 작업 프로세서로 사용할 수 있지만 구성 방식이 SQL 데이터베이스와 다릅니다. 두 연결 모두 유료 기능입니다. 전체 필드 목록은 Apidog 문서에서 확인하세요.

MongoDB

MongoDB 데이터베이스 작업에서는 SQL 대신 Operation Type을 선택합니다.

  • Find
  • Insert
  • Update
  • Delete
  • Run Database Command

CRUD 작업에는 Collection Name이 필요합니다. Query Condition에는 JSON을 입력합니다.

{ "_id": "65486728456e79993a150f1c" }
Enter fullscreen mode Exit fullscreen mode

Apidog는 일치하는 ID 문자열을 ObjectId로 자동 변환합니다. BSON 타입이 필요하면 다음 헬퍼를 사용할 수 있습니다.

ISODate(...)
ObjectId(...)
NumberDecimal(...)
NumberLong(...)
Enter fullscreen mode Exit fullscreen mode

각 타입의 저장 방식은 MongoDB 매뉴얼에서 확인할 수 있습니다.

MongoDB와 Redis 문서에는 MySQL처럼 Extract Result To Variable을 통한 JSONPath 추출 흐름이 명확히 설명되어 있지 않습니다. 따라서 먼저 시드와 상태 검증에 사용하고, 변수 추출은 콘솔 결과로 동작을 확인한 뒤 적용하세요.

Redis

Redis 연결에는 다음 값이 필요합니다.

  • Host
  • Port
  • Password
  • Database Index

시각적 작업에서는 GET, SET, DELETE를 지원합니다. 예를 들어 캐시된 세션을 조회하려면 GET을 선택하고 키를 입력합니다.

user:session:123
Enter fullscreen mode Exit fullscreen mode

드롭다운에 없는 명령은 Run Redis Command에서 실행할 수 있습니다.

KEYS user:*
Enter fullscreen mode Exit fullscreen mode

이 방식으로 다음을 검증할 수 있습니다.

  • API가 생성해야 하는 캐시 항목이 존재하는지
  • 테스트 전 캐시를 제거할 수 있는지
  • 특정 엔드포인트가 캐시를 다시 채우는지

고급 패턴과 제한 사항

대규모 테스트 스위트를 구성할 때 다음 사항을 고려하세요.

  • 루프: ForEach 단계에서 현재 항목은 {{$.StepID.element.field}}로 참조합니다. StepID에는 실제 루프 단계 번호를 사용합니다.
  • DB 값 기반 분기: 상태 값을 추출한 뒤 paid와 pending에 따라 이후 시나리오를 분기할 수 있습니다. API 테스트 시나리오의 조건부 로직과 함께 사용하세요.
  • 환경 라우팅: 환경별로 연결을 만들면 선택한 환경에 맞는 데이터베이스 연결을 사용할 수 있습니다.
  • 저장 프로시저: 시각적 인터페이스는 저장 프로시저와 같은 복잡한 작업을 지원하지 않습니다. SQL은 단순한 SELECT, INSERT, UPDATE, DELETE 문으로 유지하세요.
  • Oracle: Oracle 연결 전에는 로컬 컴퓨터에 Oracle Client를 별도로 설치해야 합니다.

환경별 자격 증명 처리

테스트가 프로덕션 데이터에 영향을 주지 않도록 환경마다 별도 연결을 만드세요.

예시:

  • local: 로컬 개발 데이터베이스
  • staging: 스테이징 데이터베이스

오른쪽 상단의 환경 드롭다운에서 환경을 전환하면, Apidog는 현재 선택된 환경과 일치하는 연결을 사용합니다. 즉, SQL을 수정하지 않아도 동일한 시나리오를 로컬 또는 스테이징 데이터베이스에서 실행할 수 있습니다.

자격 증명은 로컬에 저장되고 동기화되지 않으므로, 프로덕션 비밀번호가 공유 프로젝트에 노출되는 것을 방지할 수 있습니다.

Apidog CLI로 CI 자동화

앱에서 시나리오가 통과했다면 CI에서도 헤드리스로 실행하세요. 그러면 모든 풀 리퀘스트에서 HTTP 계약뿐 아니라 데이터베이스 상태까지 검증할 수 있습니다.

먼저 CLI를 설치하고 인증합니다.

npm install -g apidog-cli
apidog login --with-token <YOUR_ACCESS_TOKEN>
Enter fullscreen mode Exit fullscreen mode

그다음 시나리오 ID와 환경 ID를 지정해 실행합니다.

apidog run --access-token $APIDOG_ACCESS_TOKEN -t <scenario_id> -e <env_id> -r cli
Enter fullscreen mode Exit fullscreen mode

옵션 의미는 다음과 같습니다.

  • -t: 테스트 시나리오 ID
  • -e: 환경 ID
  • -r: 리포터

리포터는 cli, html, junit을 사용할 수 있으며, 여러 리포터는 쉼표로 구분합니다.

apidog run --access-token $APIDOG_ACCESS_TOKEN -t <scenario_id> -e <env_id> -r html,cli
Enter fullscreen mode Exit fullscreen mode

데이터베이스 연결 정보는 로컬에 저장되므로, CI 러너가 데이터베이스에 접근할 수 있도록 별도의 구성을 준비해야 합니다. 데이터셋 기반으로 여러 시나리오 행을 실행하려면 Apidog CLI를 사용한 데이터 기반 테스트를 참고하세요. 정기 실행은 Apidog를 사용한 API 테스트 스케줄링에서 설정할 수 있습니다.

자주 묻는 질문

어떤 데이터베이스가 무료인가요?

MySQL, SQL Server(2014 이상), PostgreSQL, Oracle은 무료 플랜에서 사용할 수 있습니다. ClickHouse, MongoDB, Redis는 유료 플랜이 필요합니다.

데이터베이스 값을 다음 요청에서 사용할 수 있나요?

가능합니다. 사후 프로세서에서 SELECT를 실행한 뒤 Extract Result To Variable로 결과를 변수에 저장하세요.

예를 들어:

SELECT fulfillment_ref
FROM orders
WHERE id = {{order_id}};
Enter fullscreen mode Exit fullscreen mode

JSONPath는 다음처럼 설정합니다.

$[0].fulfillment_ref
Enter fullscreen mode Exit fullscreen mode

이후 요청에서 {{fulfillment_ref}}를 사용하면 됩니다.

팀원이 내 데이터베이스 연결을 자동으로 받을 수 있나요?

아니요. 연결 자격 증명은 각 사용자 컴퓨터에 로컬로 저장되며 클라우드에 동기화되지 않습니다.

MySQL 8 연결이 실패하는 이유는 무엇인가요?

기본 caching_sha2_password 인증 플러그인 때문일 수 있습니다. 테스트 사용자를 mysql_native_password로 전환한 뒤 재시도하세요.

저장 프로시저를 실행할 수 있나요?

시각적 인터페이스에서는 지원되지 않습니다. 테스트 단계는 표준 SQL 문으로 구성하세요.

마무리

데이터베이스 쿼리를 추가하면 API 테스트를 “응답이 올바르다” 수준에서 “실제 데이터가 정확하다” 수준으로 확장할 수 있습니다.

구현 순서는 단순합니다.

  1. 사전 프로세서에서 알려진 상태를 시드합니다.
  2. API 요청을 실행합니다.
  3. 사후 프로세서에서 저장된 행을 조회합니다.
  4. 결과를 단언하거나 다음 요청 변수로 추출합니다.
  5. 환경별 연결로 로컬과 스테이징을 안전하게 분리합니다.

Apidog를 다운로드한 뒤 개발 데이터베이스에 MySQL 연결을 설정하고, 다음 API 요청이 생성하는 행을 SELECT로 다시 읽어보세요. 그것이 HTTP 응답을 넘어 실제 영속 상태를 검증하는 가장 빠른 시작점입니다.

Top comments (0)