1주차 과제는 본 코스의 사전 과제인 게시판 서비스를 확장하는 것이다.
첫 과제이고 이후에 지속될 팀플에 대비하는 것이 가장 중요하다고 판단한 과제였다.
과제 요구사항에 있어서 DB는 mongodb로 확정이 되어 있었기에, 3인의 팀 구성중에 mongodb atlas까지 활용해본 적이 있는 멤버가 DB를 담당하게 되었고,
기존 과제의 연장이기에, 이에 대해 비교적 초기 구성이 괜찮았던 멤버가 REST API 작업을 담당하기로 했다.
그리고 내가 최종 결과물의 검증,배포 및 git repository 관리를 위한 QA, Devops를 맡아 진행을 하였다.
내가 가장 최우선으로 작업을 했던 부분은 배포를 위한 클라우드 설정이었고 Google Cloud Platform을 사용하였다.
AWS에 비해서 인터페이스가 조금 불편하기는 했지만, 기본적으로 클라우드에 사용할 OS, ssh 클라이언트를 이용한 접속을 위해 keygen과 public key 등록, 인바운드 네트워크 사용을 위한 방화벽 설정으로 AWS와 차이는 없었다.
시스템 설정이 끝나고, 이전 직장에서 일했던 경험을 되살려 github PAT와 credential helper를 설정했다. remote repository 기능이 정상인 것을 확인하고, ssh 클라이언트를 종료를 하더라도, 실행한 nodejs 프로그램이 계속 실행될 수 있도록 PM2 설정을 했다. ecosystem 파일에서 환경변수 및 실행 스크립트를 설정을 완료한 뒤에야, 이제 내가 처음으로 경험해보는 QA 과정을 시작하게 됐다.
REST API를 테스트하는게 완전히 처음은 아니다. Postman이나 curl, 혹은 아예 테스트용 client를 js로 작성해서 돌리는 등, 몇가지 경험은 해보았다. 하지만, 사실상 Unit Test에 가까운 수준의 아주 기초적인 기능만 활용을 했고, 무엇보다도 Postman에서 제공하는 강력한 기능들은 이번에 제대로 접해보게 되었다.
Pre-request script와 Tests
authentication이 사전에 필요한 요청의 경우, 매번 탭을 옮겨 다니면서 이 작업들을 하는 것들이 보통 번거로운게 아니다. 반대로 이 테스트 요청 이후에 자동으로 해당 테스트로 생긴 변화를 취소하고자 하는 요청을 보내고 싶다면? 그럴때 필요한게 이 Pre-request script와 Tests 옵션이다.
Pre-request script는 해당 요청이 전송되기 전에, 먼저 실행되는 js 코드이다. 이를 이용해서 사전에 인증 정보에 대한 요청을 하거나, Collection 또는 Environments 수준의 변수를 설정하여 이를 참조하는 요청의 header나 body, query가 사용할 수 있도록 한다.
Tests는 Pre-request script와는 반대로 해당 요청에 대한 응답이 수신된 후에 실행되는 js 코드이다. 다만 이름에서도 보이다시피 Pre-request script와 가장 큰 차이점은, 후술할 Collection 단위의 반복되는 실행 테스트를 위해 요청과 응답이 의도한대로 진행되었는지를 판단하는 기준이 된다.
Collections
실제 배포가 되었을때, 자주 발생할만한 일련의 연속적인 작업들을 하나의 기능으로써 묶는다면, 좀 더 실질적인 테스트가 가능할 것이다. 또한 이런 테스트들을 조직내에서 더 쉽게 공유가 가능하다면 이런 테스트 방법에서도 생산성이 증가하게 되는 것은 덤이다.
Collections는 여러개의 request를 하나로 묶어 공통의 환경을 갖도록 설정하고, Pre-request Script와 Tests를 포함하여 순차적으로 실행되도록 구성해준다. 심지어 이를 반복적으로 실행하여, 데이터베이스에 점점 더 많은 자료가 쌓이게 되는 경우에 대해서도 테스트가 가능해진다.