Robot Framework는 테스트를 코드가 아니라 사람이 읽을 수 있는 키워드 테이블로 작성합니다. API 테스트에서는 RequestsLibrary가 HTTP 호출을 Create Session, GET On Session, Status Should Be 같은 키워드로 노출하므로 QA와 개발자가 같은 테스트 스위트를 읽고 유지보수할 수 있습니다.
이 글에서는 Robot Framework로 API 테스트를 자동화하는 기본 흐름을 구현합니다. 설치, 첫 테스트 작성, 세션 관리, 상태 코드 및 JSON 응답 검증, 재사용 가능한 키워드 구성, CI 실행까지 실제 .robot 파일에서 사용할 수 있는 예제로 정리합니다.
Robot Framework가 API 테스트에 적합한 이유
Robot Framework는 테스트 자동화와 RPA를 위한 오픈 소스 범용 자동화 프레임워크입니다. 핵심은 키워드 기반 문법입니다. 테스트는 테이블 형태로 작성하고, 실제 동작은 Python 또는 Java로 구현된 키워드 라이브러리를 통해 실행합니다.
API 테스트에서 특히 유용한 점은 두 가지입니다.
- 테스트가 자연어에 가까워 비개발자도 검증 내용을 읽을 수 있습니다.
- RequestsLibrary, JSONLibrary 같은 라이브러리를 조합해 HTTP 요청과 JSON 검증을 키워드로 처리할 수 있습니다.
키워드 기반 테스트가 다른 자동화 방식과 어떻게 다른지 알고 싶다면 자동화 테스트 프레임워크 가이드도 참고할 수 있습니다.
Robot Framework 및 라이브러리 설치
프로젝트별 의존성을 분리하려면 가상 환경에서 설치합니다.
python -m venv .venv
source .venv/bin/activate
pip install robotframework
pip install robotframework-requests
pip install robotframework-jsonlibrary
각 패키지의 역할은 다음과 같습니다.
-
robotframework: 테스트 러너와 핵심 엔진 -
robotframework-requests: HTTP 요청을 보내는 RequestsLibrary -
robotframework-jsonlibrary: JSONPath 기반 JSON 값 추출 및 검증
설치 확인:
robot --version
문법이 헷갈릴 때는 공식 Robot Framework 사용자 가이드를 확인하세요.
주의할 점은 공백입니다. Robot Framework는 키워드와 인수를 최소 두 칸 이상의 공백으로 구분합니다. 테스트가 파싱되지 않는다면 라이브러리 import보다 먼저 공백을 확인하는 것이 좋습니다.
첫 번째 API 테스트 작성
Robot Framework 테스트 파일은 .robot 확장자를 사용합니다. 일반적으로 다음 섹션으로 구성합니다.
-
*** Settings ***: 사용할 라이브러리 선언 -
*** Variables ***: 기본 URL, 공통 값 선언 -
*** Test Cases ***: 실행할 테스트 케이스 작성
예시:
*** Settings ***
Library RequestsLibrary
Library Collections
*** Variables ***
${BASE_URL} https://api.example.com/v1
*** Test Cases ***
Get User Returns 200
Create Session api ${BASE_URL}
${response}= GET On Session api /users/42
Status Should Be 200 ${response}
Get User Returns Expected Fields
Create Session api ${BASE_URL}
${response}= GET On Session api /users/42
${body}= Set Variable ${response.json()}
Should Be Equal As Integers ${body}[id] 42
Should Be Equal ${body}[status] active
실행:
robot tests.robot
실행 후 Robot Framework는 기본적으로 다음 파일을 생성합니다.
output.xmllog.htmlreport.html
테스트 결과를 디버깅할 때는 log.html을 먼저 열어 각 키워드의 실행 결과를 확인하면 됩니다.
세션으로 인증 상태 재사용하기
Create Session은 기본 URL만 저장하지 않습니다. 헤더, 쿠키, 인증 정보도 세션에 연결할 수 있습니다. 로그인 후 토큰을 받아 여러 요청에서 재사용하는 API 테스트에 적합합니다.
*** Settings ***
Library RequestsLibrary
Library Collections
*** Variables ***
${BASE_URL} https://api.example.com/v1
*** Test Cases ***
Create Order With Authenticated Session
Create Session api ${BASE_URL}
${login}= POST On Session api /auth/login
... json={"email": "qa@example.com", "password": "test-pass"}
${token}= Set Variable ${login.json()}[token]
${headers}= Create Dictionary Authorization=Bearer ${token}
${order}= POST On Session api /orders
... json={"product_id": 7, "quantity": 2}
... headers=${headers}
Status Should Be 201 ${order}
여기서 ...는 한 키워드 호출을 여러 줄로 나눌 때 사용합니다. 요청 본문이나 헤더가 길어질 때 가독성을 유지하는 데 유용합니다.
RequestsLibrary의 세션 관련 키워드는 RequestsLibrary 참조에서 확인할 수 있습니다.
응답 본문 검증하기
상태 코드만 확인하면 API가 실제로 올바른 데이터를 반환했는지 알 수 없습니다. JSON 응답의 필드 존재 여부, 값, 타입을 함께 검증해야 합니다.
*** Settings ***
Library RequestsLibrary
Library JSONLibrary
Library Collections
*** Variables ***
${BASE_URL} https://api.example.com/v1
*** Test Cases ***
Order Response Has Correct Shape
Create Session api ${BASE_URL}
${response}= POST On Session api /orders
... json={"product_id": 7, "quantity": 2}
Status Should Be 201 ${response}
${body}= Set Variable ${response.json()}
Dictionary Should Contain Key ${body} total
Should Be Equal As Integers ${body}[quantity] 2
${status}= Get Value From Json ${body} $.status
Should Be Equal ${status}[0] pending
실무에서 자주 쓰는 검증 방식은 다음과 같습니다.
Dictionary Should Contain Key ${body} id
Should Not Be Empty ${body}[id]
Should Be Equal As Integers ${body}[quantity] 2
Should Contain ${body}[status] pending
Get Value From Json은 JSONPath를 사용하므로 중첩된 응답을 검증할 때 유용합니다.
API 응답에서 어떤 항목을 검증해야 하는지 정리하려면 API 어설션 가이드를 참고하세요.
재사용 가능한 키워드 만들기
로그인, 세션 생성, 공통 헤더 생성 같은 흐름을 모든 테스트에 반복하면 유지보수가 어려워집니다. Robot Framework에서는 *** Keywords *** 섹션에 사용자 지정 키워드를 정의해 공통 로직을 분리할 수 있습니다.
*** Settings ***
Library RequestsLibrary
Library Collections
*** Variables ***
${BASE_URL} https://api.example.com/v1
*** Keywords ***
Authenticate And Open Session
Create Session api ${BASE_URL}
${login}= POST On Session api /auth/login
... json={"email": "qa@example.com", "password": "test-pass"}
${token}= Set Variable ${login.json()}[token]
Set Suite Variable ${AUTH_TOKEN} ${token}
Create Auth Headers
${headers}= Create Dictionary Authorization=Bearer ${AUTH_TOKEN}
RETURN ${headers}
*** Test Cases ***
Create Order
Authenticate And Open Session
${headers}= Create Auth Headers
${order}= POST On Session api /orders
... json={"product_id": 7, "quantity": 2}
... headers=${headers}
Status Should Be 201 ${order}
이 구조의 장점은 명확합니다.
- 로그인 API가 바뀌어도 키워드 하나만 수정하면 됩니다.
- 테스트 케이스는 “무엇을 검증하는지”에 집중할 수 있습니다.
- 공통 인증, 헤더, 요청 생성 로직을 여러 스위트에서 재사용할 수 있습니다.
자동화 테스트를 모듈화하는 방식은 자동화된 테스트 스크립트 작성 방법에서도 같은 원칙으로 설명됩니다.
리소스 파일로 공통 키워드 분리하기
스위트가 커지면 공통 키워드를 별도 리소스 파일로 옮기는 것이 좋습니다.
예를 들어 common.robot 파일을 만듭니다.
*** Settings ***
Library RequestsLibrary
Library Collections
*** Variables ***
${BASE_URL} https://api.example.com/v1
*** Keywords ***
Authenticate And Open Session
Create Session api ${BASE_URL}
${login}= POST On Session api /auth/login
... json={"email": "qa@example.com", "password": "test-pass"}
${token}= Set Variable ${login.json()}[token]
Set Suite Variable ${AUTH_TOKEN} ${token}
Create Auth Headers
${headers}= Create Dictionary Authorization=Bearer ${AUTH_TOKEN}
RETURN ${headers}
테스트 파일에서는 Resource로 가져옵니다.
*** Settings ***
Resource common.robot
*** Test Cases ***
Create Order
Authenticate And Open Session
${headers}= Create Auth Headers
${order}= POST On Session api /orders
... json={"product_id": 7, "quantity": 2}
... headers=${headers}
Status Should Be 201 ${order}
일반적인 프로젝트 구조는 다음과 같이 가져갈 수 있습니다.
tests/
users.robot
orders.robot
resources/
common.robot
auth.robot
users_keywords.robot
orders_keywords.robot
테스트 케이스와 지원 로직을 분리하면 키워드 기반 구조를 더 오래 유지할 수 있습니다. 이 접근 방식이 확장 가능한 이유는 자동화 테스트 프레임워크 가이드에서도 다룹니다.
CI에서 Robot Framework 실행하기
Robot Framework는 CLI로 실행되며 테스트 실패 시 0이 아닌 종료 코드를 반환합니다. 따라서 CI/CD 파이프라인에서 빌드 실패 조건으로 사용하기 쉽습니다.
기본 실행:
robot tests/
결과 폴더 지정:
robot --outputdir results tests/
환경별 기본 URL 주입:
robot --outputdir results --variable BASE_URL:https://staging.example.com/v1 tests/
태그를 사용하면 스모크 테스트와 전체 테스트를 분리할 수 있습니다.
*** Test Cases ***
Get User Returns 200
[Tags] smoke users
Create Session api ${BASE_URL}
${response}= GET On Session api /users/42
Status Should Be 200 ${response}
스모크 테스트만 실행:
robot --include smoke --outputdir results tests/
특정 태그 제외:
robot --exclude slow --outputdir results tests/
CI 흐름은 보통 다음 순서입니다.
- Python 설치
- 의존성 설치
-
robot명령 실행 -
log.html,report.html,output.xml을 아티팩트로 업로드
GitHub Actions나 다른 파이프라인에서 API 테스트를 실행하는 패턴은 CI/CD의 API 테스트 가이드와 동일합니다.
전용 API 플랫폼이 더 적합한 경우
Robot Framework는 키워드 기반의 읽기 쉬운 테스트를 작성하고, 다양한 기술 수준의 팀원이 같은 스위트를 검토해야 할 때 좋은 선택입니다.
다만 다음 작업까지 한 곳에서 처리하려면 전용 API 플랫폼이 더 편할 수 있습니다.
- API 설계
- 목 서버 구성
- 요청 디버깅
- OpenAPI 기반 스키마 검증
- 환경 관리
- 데이터 기반 실행
- HTML 리포트와 CLI 실행
Apidog는 시각적 테스트 빌더, 자동 OpenAPI 스키마 유효성 검사, CSV 및 JSON 기반 데이터 실행, 환경 관리, HTML 보고서, CI용 CLI 러너를 제공합니다.
실무에서는 두 방식을 함께 쓰는 경우도 많습니다. 키워드 기반 가독성이 중요한 테스트는 Robot Framework로 작성하고, API 설계·목킹·디버깅·광범위한 API 테스트는 Apidog에서 관리하는 방식입니다. Apidog를 다운로드하면 별도 키워드 라이브러리 작성 없이 API 테스트 스위트를 구성할 수 있습니다.
자주 묻는 질문
Robot Framework는 UI 테스트 전용인가요?
아닙니다. Robot Framework는 범용 자동화 프레임워크입니다. SeleniumLibrary로 UI 테스트에 널리 쓰였지만, RequestsLibrary를 사용하면 API 테스트도 처리할 수 있습니다. 데이터베이스, SSH 등 다른 영역도 라이브러리로 확장할 수 있습니다.
Create Session과 일반 요청의 차이점은 무엇인가요?
Create Session은 기본 URL, 헤더, 쿠키, 인증 정보를 저장하는 명명된 HTTP 세션을 만듭니다. 이후 GET On Session, POST On Session 같은 키워드는 해당 상태를 재사용합니다.
세션이 없으면 요청 간 쿠키나 인증 정보가 유지되지 않으므로 매 요청마다 필요한 정보를 다시 전달해야 합니다.
Robot Framework를 사용하려면 Python을 알아야 하나요?
테스트 작성에는 필요하지 않습니다. Robot Framework의 키워드 테이블 문법은 비프로그래머도 읽을 수 있도록 설계되었습니다. RequestsLibrary도 HTTP 작업을 이미 키워드로 제공합니다.
Python 지식은 완전히 새로운 키워드 라이브러리를 직접 만들 때만 필요합니다. 대부분의 API 테스트는 기존 라이브러리로 충분히 시작할 수 있습니다.
API 테스트에서 Robot Framework는 pytest와 어떻게 다른가요?
pytest는 코드 우선 방식입니다. Python 코드 옆에 테스트를 두고 개발자가 직접 유지보수하는 팀에 잘 맞습니다.
Robot Framework는 키워드 기반 방식입니다. 테스트를 테이블 형태로 읽기 쉽게 작성하고, QA·개발자·제품 담당자가 함께 검토해야 하는 팀에 적합합니다.
둘 다 CI에서 실행할 수 있고 보고서를 생성할 수 있습니다. 선택 기준은 기능 차이보다 “누가 테스트를 작성하고 유지보수하는가”에 가깝습니다.
Robot Framework는 OpenAPI 스키마에 대해 응답 유효성을 검사할 수 있나요?
기본 기능만으로는 자동 OpenAPI 스키마 검증을 제공하지 않습니다. 내장 키워드와 JSONLibrary로 개별 필드를 검증할 수 있고, 커뮤니티 라이브러리를 추가해 스키마 검사를 구성할 수 있습니다.
OpenAPI 문서 기반 자동 유효성 검사가 핵심 워크플로우라면, Apidog처럼 이를 기본 제공하는 플랫폼을 사용하는 편이 라이브러리 조립과 유지보수 부담을 줄일 수 있습니다.
Top comments (0)