Testing Web APIs with Postman Collections 정보
기타 Testing Web APIs with Postman Collections
본문
https://www.baeldung.com/postman-testing-collections
1. Introduction
웹 API를 철저히 테스트하려면 API 끝점에 액세스하기 위한 일종의 웹 클라이언트가 필요합니다. Postman은 서비스 외부에서 HTTP 요청을 만들어 웹 API를 실행하는 독립 실행형 도구입니다.
Postman을 사용할 때 우리는 테스트를 위해서 HTTP 클라이언트 인프라 코드를 작성할 필요가 없습니다. 대신 콜렉션이라는 테스트 스위트를 작성하여 Postman이 API와 상호 작용하도록 합니다.
이 자습서에서는 REST API를 테스트 할 수있는 우편 게시자 콜렉션을 만드는 방법을 살펴 보겠습니다.
2. Setup
컬렉션을 시작하기 전에 환경을 설정해야합니다.
2.1. Installing Postman
Postman는 Linux, Mac 및 Windows에서 사용할 수 있습니다. 이 도구는 Postman 웹 사이트에서 다운로드하여 설치할 수 있습니다.
스플래시 화면을 닫은 후 사용자 인터페이스를 볼 수 있습니다.
2.2. Running the Server
Postman은 요청을 처리하기 위해 실시간 HTTP 서버가 필요합니다. 이 튜토리얼에서는 GitHub에서 사용할 수있는 이전의 Baeldung 프로젝트 인 spring-boot-rest를 사용합니다.
제목에서 짐작할 수 있듯이, spring-boot-rest는 Spring Boot 응용 프로그램입니다. Maven 목표 설치로 앱을 빌드합니다. 일단 빌드되면 커스텀 메이븐 목표 인 spring-boot :를 실행하여 서버를 시작합니다.
서버가 실행 중인지 확인하려면 브라우저에서 다음 URL을 누르십시오.
이 서비스는 메모리 내 데이터베이스를 사용합니다. 서버가 중지되면 모든 레코드가 지워집니다.
3. Creating a Postman Collection
Postman의 콜렉션은 일련의 HTTP 요청입니다. Postman는 헤더 및 메시지 본문을 포함하여 요청의 모든 측면을 저장합니다. 따라서 우리는 반자동 테스트로 순서대로 요청을 실행할 수 있습니다.
새 컬렉션을 만들어 보겠습니다. 새로 만들기 버튼의 드롭 다운 화살표를 클릭하고 컬렉션을 선택할 수 있습니다.
새로 만들기 만들기 대화 상자가 나타나면 우리의 콜렉션에 "foo API test"라는 이름을 붙일 수 있습니다. 마지막으로 생성 버튼을 클릭하면 새 컬렉션이 왼쪽의 목록에 나타납니다.
컬렉션이 생성되면 두 개의 메뉴 버튼이 표시되도록 커서를 가져갈 수 있습니다. 화살표 버튼은 Collection Runner에 대한 액세스를 제공하는 당겨 받기 권한 패널을 엽니 다. 반대로 줄임표 단추는 컬렉션에 대한 여러 작업이 포함 된 드롭 다운 메뉴를 엽니 다.
4. Adding a POST Request
4.1. Creating a New Request
이제 콜렉션이 비었으므로 우리 API에 맞는 요청을 추가합시다. 특히, URI/auth/foos에 POST 메시지를 보냅니다. 그렇게하기 위해 우리는 우리 컬렉션에 줄임표 메뉴(...)를 열고 Add Request를 선택한다.
SAVE REQUEST 대화 상자가 나타나면 "add a foo"와 같은 설명이 포함 된 이름을 입력하십시오. 그런 다음 foo API 테스트에 저장 버튼을 클릭하십시오.
요청이 만들어지면 우리 컬렉션에 하나의 요청이 있음을 알 수 있습니다. 그러나 Google의 컬렉션이 확장되지 않은 경우 아직 요청을 볼 수 없습니다. 이 경우 컬렉션을 클릭하여 확장 할 수 있습니다.
이제 우리는 새로운 요청을 우리 컬렉션 아래에 나열해야합니다. 새로운 요청은 기본적으로 HTTP GET이며 우리가 원하는 것은 아닙니다. 다음 섹션에서 이를 수정합니다.
4.2. Editing the Request
요청을 편집하려면 요청을 클릭하여 요청 편집기 탭에 로드하십시오.
요청 편집기에는 다양한 옵션이 있지만 지금은 그 중 일부만 필요합니다.
먼저 드롭 다운을 사용하여 메소드를 GET에서 POST로 변경해 봅시다.
둘째, URL이 필요합니다. 메소드 드롭 다운의 오른쪽에는 요청 URL에 대한 텍스트 상자가 있습니다. 자 이제 입력 해 봅시다.
http ://localhost:8082/spring-boot-rest/auth/foos
마지막 단계는 메시지 본문을 제공하는 것입니다. URL 주소 아래에는 탭 Body 행이 있습니다. 본문 편집기로 가려면 본문 탭 Bodys을 클릭합니다.
본문 탭의 텍스트 영역 바로 위에는 라디오 버튼과 드롭 다운 행이 있습니다. 이것들은 요청의 서식과 내용 유형을 제어합니다.
Google 서비스는 JSON 데이터를 허용하므로 Raw 라디오 버튼을 선택합니다. 오른쪽의 드롭 다운에서 JSON (application/json) 콘텐츠 유형을 적용합니다.
인코딩과 내용 유형이 설정되면 JSON 내용을 텍스트 영역에 추가합니다.
{
"name": "Transformers"
}
마지막으로 Ctrl-S를 누르거나 저장 버튼을 눌러 변경 사항을 저장하십시오. 저장 단추는 보내기 단추의 오른쪽에 있습니다. 저장하면 요청이 왼쪽의 목록에서 POST로 업데이트되었음을 알 수 있습니다.
5. Running the Request
5.1. Running a Single Request
단일 요청을 실행하려면 URL 주소 오른쪽에 있는 보내기 버튼을 클릭하기 만하면 됩니다. 보내기를 클릭하면 응답 패널이 요청 패널 아래에 열립니다. 그것을 보려면 아래로 스크롤해야 할 수도 있습니다.
결과를 살펴 봅시다. 특히, 헤더 바에서 요청이 201 Created 상태로 성공한 것을 볼 수 있습니다. 또한 응답 본문에는 Transformers 레코드에 ID가 1 인 것으로 표시됩니다.
5.2. Using the Collection Runner
보내기 단추와 달리 컬렉션 실행자는 전체 컬렉션을 실행할 수 있습니다. 콜렉션 러너를 시작하기 위해 우리는 foo API 테스트 콜렉션 위로 커서를 가져간 다음 화살표를 클릭한다. 오른쪽 패널에서 실행 버튼을 볼 수 있으므로 클릭하십시오.
실행 버튼을 클릭하면 수집 러너가 새 창에서 열립니다. 우리는 컬렉션에서 그것을 시작했기 때문에 러너는 이미 컬렉션에 초기화되어 있습니다.
수집 러너는 테스트 실행에 영향을 미치는 옵션을 제공하지만이 연습에서는 필요하지 않습니다. 하단의 Run foo API 테스트 버튼으로 직접 이동하여 클릭하십시오.
컬렉션을 실행하면 보기가 실행 결과로 변경됩니다. 이보기에서는 성공한 경우 녹색으로 표시되고 실패한 경우에는 빨간색으로 표시된 테스트 목록이 표시됩니다.
요청이 전송되었지만 주자는 0 테스트가 통과했고 0 테스트가 실패했음을 나타냅니다. 이는 요청에 아직 테스트를 추가하지 않았기 때문입니다.
6. Testing the Response
6.1. Adding Tests to a Request
테스트를 만들려면 POST 메서드를 빌드 한 요청 편집 패널로 돌아가십시오. URL 아래에있는 테스트 탭을 클릭합니다. 테스트 패널이 나타나면 테스트 패널이 나타납니다.
[테스트] 패널에는 서버에서 응답을받을 때 실행되는 JavaScript가 작성됩니다.
Postman은 요청 및 응답에 대한 액세스를 제공하는 기본 제공 변수를 제공합니다. 또한 require () 구문을 사용하여 많은 JavaScript 라이브러리를 가져올 수 있습니다.
이 튜토리얼에서 다루는 스크립트 기능이 너무 많습니다. 그러나 공식적인 Postman 문서는 이 주제에 대한 훌륭한 자료입니다.
요청에 세 가지 테스트를 추가하여 계속하겠습니다.
pm.test("success status", () => pm.response.to.be.success );
pm.test("name is correct", () =>
pm.expect(pm.response.json().name).to.equal("Transformers"));
pm.test("id was assigned", () =>
pm.expect(pm.response.json().id).to.be.not.null );
우리가 볼 수 있듯이이 테스트는 Postman가 제공 한 전역 pm 모듈을 사용합니다. 특히 테스트에서는 pm.test (), pm.expect () 및 pm.response를 사용합니다.
pm.test () 함수는 레이블과 expect ()와 같은 어설 션 함수를 허용합니다. 우리는 pm.expect ()를 사용하여 응답 JSON의 내용에 대한 조건을 제시합니다.
pm.response 객체는 서버에서 반환 된 응답에 대한 다양한 속성 및 작업에 대한 액세스를 제공합니다. 사용 가능한 속성에는 응답 상태 및 JSON 콘텐츠가 포함됩니다.
언제나처럼 Ctrl-S 또는 저장 버튼을 사용하여 변경 사항을 저장합니다.
6.2. Running the Tests
테스트가 완료되었으므로 요청을 다시 실행 해 봅시다. 보내기 버튼을 누르면 응답 패널의 테스트 결과 탭에 결과가 표시됩니다.
마찬가지로, 수집 주자는 이제 우리의 테스트 결과를 표시합니다. 특히 왼쪽 상단의 요약에는 업데이트 된 합계 및 실패한 합계가 표시됩니다. 다음은 각 테스트의 상태를 보여주는 목록입니다.
6.3. Viewing the Postman Console
포스트맨 콘솔은 스크립트를 만들고 디버깅하는 데 유용한 도구입니다. 보기 메뉴에서 콘솔에 Postman Console 표시 항목이있는 콘솔을 찾을 수 있습니다. 실행되면 콘솔이 새 창에서 열립니다.
콘솔이 열려있는 동안 콘솔은 모든 HTTP 요청과 응답을 기록합니다. 또한 스크립트에서 console.log ()를 사용하면 우편 발송 콘솔에 다음 메시지가 표시됩니다.
7. Creating a Sequence of Requests
지금까지 단일 HTTP 요청에 중점을 두었습니다. 이제 여러 요청을 통해 우리가 할 수있는 일을 살펴 보겠습니다. 일련의 요청을 연결하여 클라이언트 - 서버 워크 플로를 시뮬레이션하고 테스트 할 수 있습니다.
이 섹션에서는 일련의 요청을 만들기 위해 우리가 배운 것을 적용 해 보겠습니다. 특히, 우리가 이미 생성 한 POST 요청 후에 실행하기 위해 세 가지 요청을 더 추가 할 것입니다. 이것들은 GET, DELETE 그리고 마지막으로 또 다른 GET이 될 것입니다.
7.1. Capturing Response Values in Variables
새 요청을 만들기 전에 기존 POST 요청을 수정 해 보겠습니다. 서버가 어느 id에 각 foo 인스턴스를 할당할지 모르기 때문에 변수를 사용하여 서버에서 반환 한 ID를 캡처 할 수 있습니다.
이 id를 캡처하기 위해 POST 요청의 테스트 스크립트 끝에 한 줄 더 추가합니다.
pm.variables.set("id", pm.response.json().id);
pm.variables.set () 함수는 값을 가져 와서 임시 변수에 할당합니다. 이 경우 객체의 id 값을 저장하기 위해 id 변수를 생성합니다. 일단 설정되면, 이후의 요청에서이 변수에 액세스 할 수 있습니다.
7.2. Adding a GET Request
이제 이전 섹션의 기술을 사용하여 POST 요청 후에 GET 요청을 추가합시다.
이 GET 요청을 통해 우리는 POST 요청과 동일한 foo 인스턴스를 검색 할 것이다. 이 GET 요청을 "get a foo"라고 명명합시다.
GET 요청의 URL은 다음과 같습니다.
http://localhost:8082/spring-boot-rest/auth/foos/{{id}}
이 URL에서는 POST 요청 중에 이전에 설정 한 id 변수를 참조합니다. 따라서 GET 요청은 POST에 의해 작성된 동일한 인스턴스를 검색해야합니다.
스크립트 외부에 나타나는 변수는 이중 중괄호 구문 {{id}}을 사용하여 참조됩니다.
GET 요청에 대한 본문이 없으므로 직접 테스트 탭으로 넘어 갑시다. 테스트가 비슷하기 때문에 POST 요청에서 테스트를 복사 한 다음 몇 가지 사항을 변경할 수 있습니다.
첫째, id 변수를 다시 설정할 필요가 없으므로 해당 행을 복사하지 마십시오.
두 번째로, 우리는이 시간에 어떤 이드를 기대하는지 알기 때문에 그 이드를 검증 해 봅시다. id 변수를 사용하면 다음과 같이 할 수 있습니다.
pm.test("success status", () => pm.response.to.be.success );
pm.test("name is correct", () =>
pm.expect(pm.response.json().name).to.equal("Transformers"));
pm.test("id is correct", () =>
pm.expect(pm.response.json().id).to.equal(pm.variables.get("id")) );
이중 중괄호 구문은 유효한 JavaScript가 아니므로 pm.variables.get () 함수를 사용하여 id 변수에 액세스합니다.
마지막으로 이전에했던 것처럼 변경 사항을 저장해 봅시다.
7.3. Adding a DELETE Request
다음으로 foo 객체를 서버에서 제거하는 DELETE 요청을 추가 할 것이다.
우리는 GET 후에 새로운 요청을 추가하고 메소드를 DELETE로 설정합니다. 이 요청의 이름을 "delete a foo"라고 할 수 있습니다.
삭제 URL은 GET URL과 동일합니다.
http://localhost:8082/spring-boot-rest/auth/foos/{{id}}
응답에는 테스트 할 본문이 없지만 응답 코드를 테스트 할 수 있습니다. 따라서 DELETE 요청에는 테스트가 하나만 있습니다.
pm.test("success status", () => pm.response.to.be.success );
7.4. Verifying the DELETE
마지막으로 DELETE가 실제로 작동하는지 확인하기 위해 GET 요청의 또 다른 사본을 추가하자. 이번에는 처음부터 요청을 만드는 대신 첫 번째 GET 요청을 복제 해 봅시다.
요청을 복제하려면 요청을 마우스 오른쪽 버튼으로 클릭하여 드롭 다운 메뉴를 표시하십시오. 그런 다음 Duplicate를 선택합니다.
중복 요청에는 이름에 Copy라는 단어가 추가됩니다. 혼동을 피하기 위해 "삭제 확인"으로 이름을 변경합시다. 이름 바꾸기 옵션은 요청을 마우스 오른쪽 단추로 클릭하여 사용할 수 있습니다.
기본적으로 복제 요청은 원래 요청 직후 나타납니다. 따라서 DELETE 요청 아래로 끌어 와야합니다.
마지막 단계는 테스트를 수정하는 것입니다. 그러나이를 수행하기 전에 실패한 테스트를 볼 기회를 가져 보겠습니다.
우리는 DELETE 후에 GET 요청을 복사하고 옮겼습니다. 아직 테스트를 업데이트하지 않았습니다. DELETE 요청은 객체를 삭제해야하므로 테스트가 실패해야합니다.
요청을 모두 저장 한 다음 콜렉션 러너에서 다시 시도하십시오. 예상대로 테스트가 실패했습니다.
이제 간단한 우회 경로가 완료되었으므로 테스트를 수정하겠습니다.
실패한 테스트를 검토하여 서버가 500 상태로 응답 함을 알 수 있습니다. 따라서 테스트에서 상태가 변경됩니다.
또한 Postman Console에서 실패한 응답을보고 응답에 원인 속성이 포함되어 있음을 알 수 있습니다. 또한 cause 속성에는 "No value present"문자열이 포함됩니다. 다음과 같이 테스트 할 수 있습니다.
pm.test("status is 500", () => pm.response.to.have.status(500) );
pm.test("no value present", () =>
pm.expect(pm.response.json().cause).to.equal("No value present"));
7.5. Running the Full Collection
이제 모든 요청을 추가 했으므로 컬렉션 러너에서 전체 컬렉션을 실행 해 보겠습니다.
계획에 따라 모든 것이 끝나면 9 번의 성공적인 테스트를 거쳐야합니다.
8. Exporting and Importing the Collection
Postman는 우리의 수집품을 개인적인 장소에 저장하지만 수집품을 공유하고자 할 수 있습니다. 그렇게하기 위해 컬렉션을 JSON 파일로 내 보냅니다.
내보내기 명령은 콜렉션의 줄임표 메뉴에서 사용할 수 있습니다. JSON 파일 버전을 묻는 메시지가 표시되면 최신 권장 버전을 선택하십시오.
파일 버전을 선택하면 Postman에서 내 보낸 컬렉션의 파일 이름과 위치를 묻는 메시지를 표시합니다. GitHub 프로젝트 내에서 폴더를 선택할 수 있습니다.
이전에 내 보낸 모음을 가져 오려면 가져 오기 단추를 사용합니다. 주 우편함 창의 도구 모음에서 찾을 수 있습니다. Postman이 파일 위치를 묻는 메시지를 표시하면 가져 오려는 JSON 파일을 탐색 할 수 있습니다.
Postman이 내 보낸 파일을 추적하지 않는다는 점은 주목할 가치가 있습니다. 결과적으로 Postman은 컬렉션을 다시 가져올 때까지 외부 변경 사항을 표시하지 않습니다.
9. Conclusion
이 기사에서는 Postman을 사용하여 REST API에 대한 반자동 테스트를 작성했습니다. 이 기사가 Postman의 기본 기능을 소개하는 동안, 우리는 기능의 표면을 간신히 긁어 모았습니다. Postman 온라인 문서는 더 깊은 탐구를위한 귀중한 자원입니다.
이 자습서에서 생성 된 컬렉션은 GitHub에서 사용할 수 있습니다.
자바를 사용하시는 분은 spring 을 아시겠죠.. https://spring.io/
이글을 쓰신분의 강의도 있네요. https://www.baeldung.com/rest-with-spring-course#new-modules
0
댓글 0개