[일정 관리 앱] 요구사항 반영 후 API 테스트

 과제에 명시된 모든 요구사항을 반영 후 아래와 같이 구현한 기능에 대한 API 테스트를 진행해 보았다.

 

1. 일정 생성

 '일정 생성' 요청 시 일정 생성에 필요한 '할 일(본문)', '작성자 이름', '작성자 이메일', '비밀번호' 정보들을 Http 메세지 본문(Request boy) 에 담아 요청을 하도록 구현했다.

일정 생성 - 정상 요청

 

'유효한 요청 값' 들이 전달될 경우 일정을 DB 에 저장하며, 저장(생성)한 일정의 '아이디(id), 할 일(body), 작성자 이름(authorName), 일정 작성일(createAt), 일정 수정일(updateAt)' 정보를 반환해 준다. 이 때의 HttpStatus 는 '201 Created' 이다.

 

'유효하지 않은 요청 값(들)' 이 전달될 경우는 아래와 같다.

일정 생성 - 비정상 요청

 

'body, password, name' 는 모두 'null', '빈 값' 을 허용하지 않고 각각 저장될 수 있는 '최대 글자수(길이)' 가 정해져 있다. 그래서 위의 테스트 이미지를 보면 'body' 의 경우 '빈 값' 이고 'password' 의 경우 'null', 'name' 의 경우 '최대 글자수' 를 넘었기에 오류 메시지가 반환 되었으며, 이 때 HttpStatus 는 '400 Bad Request' 이다. 오류 메시지의 경우 '유효하지 않은 요청 파라미터(들)' 의 이름도 함께 반환해준다.

 

정상 요청의 경우 아래와 같이 DB 에 생성된 일정의 정보가 추가되며 비정상 요청의 경우 일정이 생성되지 않아 DB 에 추가되지 않는다.

DB schedule 테이블

DB author 테이블

 

또한 나의 경우 'author' 테이블에서 작성자의 '이메일(e_mail)' 을 고유(Unique)하게 가지도록 설정했기에 같은 이메일 정보로 일정을 생성해도 'author' 테이블에 작성자 정보가 추가되지 않도록 구현했다. '이메일' 정보가 같고 '작성자명' 이 다를 경우에는 기존 작성자 정보에서 '작성자명(name)' 을 수정한다.

 

※ 참고 : 현재 'body, passwor, name' 에 대한 유효성 검증은 구현했지만 'email' 유효성 검증에 대한 구현은 되어있지 않다.

 

 

2. 일정 수정

 생성된 일정의 '할 일, 작성자명' 을 수정할 수 있으며, 수정시에는 아래와 같은 요청 정보를 요구한다.

• 패스 파라미터 : 일정 ID
• 리퀘스트 바디 : 비밀번호, 할 일, 작성자명

일정 수정 - 정상 요청

 

요청 파라미터가 모두 유효한 경우 생성된 일정을 수정해 DB 에 반영한다. 비밀번호의 경우 DB 에 저장된 비밀번호 정보와 일치해야 하며, '일정 생성' 과 마찬가지로 'body, authorName' 는 각각 '최대 글자수' 가 설정되어 있고 'null', '빈 값' 을 허용하지 않는다. 정상 요청의 경우 수정된 일정의 정보를 반환하고 이 때 HttpStatus 는 '202 Accpted' 이다.

 

비밀번호가 유효하지 않은 경우는 아래와 같다.

일정 수정 - 비밀번호 오류

 

비밀번호가 유효하지 않음을 알리는 오류 메시지가 반환되며, HttpStatus 는 '400 Bad Request' 이다. 'body, authorName' 이 유효하지 않을 경우에는 '일정 생성' 과 같은 오류 메시지와 HttpStatus 를 반환한다.

 

DB 를 보면 유효한 요청 파라미터를 전달 받은 경우에만 DB 정보가 수정된 것을 확인할 수 있다.

DB schedule 테이블

 

일정의 '할 일' 을 수정했기에 '할 일(body)' 과 '수정일(createAt)' 에 대한 값이 변경된 것을 확인할 수 있다.

 

 

3. 일정 조회

3-1. 단건 조회

 패스 파라미터로 '일정 ID' 정보를 요구하며 해당 ID 값을 가진 일정 정보를 조회해 아래와 같이 일정 정보를 반환한다. 이 때 HttpStatus 는 '200 OK' 이다.

일정 조회 - 정상 요청

 

만약 DB 에 존재하지 않는 일정을 조회할 경우 아래와 같이 오류 메시지를 반환하고 이 때, HttpStatus 는 '404 Not Found' 이다.

일정 조회 - 비정상 요청

 

3-2. 다건 조회 (일정 목록)

 '일정 목록 조회' 의 경우 쿼리(Query String) 파라미터(수정일, 작성자명, 페이지 번호, 페이지 크기)를 검색 조건을 전달 받는다. 어떠한 조건도 없다면 모든 일정 정보를 아래와 같이 조회한다('Query Params' 의 모든 파라미터를 체크해도 모든 일정을 조회한다).

일정 목록 조회 - 정상, 검색 조건 X

 

'작성자명', '수정일', '페이지 정보(페이지 번호+페이지 크기)' 를 '검색 조건' 정보로 사용할 수 있으며, 단일 또는 복수의 조건을 통해 일정 목록을 조회할 수 있다.

 

만약 '2024-10-03' 에 작성/수정된 일정들을 '5개' 씩 나누어 페이지를 만들었다면 '2 페이지' 에서는 아래와 같은 일정 목록을 조회할 수 있다.

일정 목록 조회 - 정상 요청, 검색 조건 O

 

정상 요청시 '수정일(createAt)' 을 기준으로 '내림차순(최근순)' 정렬된 '일정 정보 리스트' 와 페이지 번호를 반환하며 이 때 HttpStatus 는 '200 OK' 이다. 만약 페이지 정보를 통해 조회할 수 있는 일정 목록이 없을 경우에는 전달받은 페이지 정보와 함께 '빈 목록' 을 반환한다.

 

'작성자명' 의 경우 '일정 생성' 과 마찬가지로 유효성을 검증 한다. '수정일' 의 경우 'YYYY-MM-DD' 형식을 지키지 않는 요청이라면 아래와 같이 에러 메시지를 반환하고 HttpStatus 는 '400 Bad Request' 이다.

일정 목록 조회 - 수정일 포맷 오류

 

 

4. 일정 삭제

 '일정 삭제' 의 경우 삭제할 일정의 'id(path parameter)' 와 '비밀번호(request body)' 를 요청 파라미터로 요구한다. '일정 수정' 과 마찬가지로 전달 받은 비밀번호가 DB 에 저장된 일정의 비밀번호와 일치해야 삭제가 수행된다. 물론 일정이 존재해야 한다. 아래는 일정을 삭제하기 전 DB 의 각 테이블의 상태이다, 

일정 삭제 전, DB schedule 테이블

일정 삭제 전, DB author 테이블

 

여기서 현재 'id = 12' 인 일정 정보를 삭제해보려 한다. 해당 일정의 경우 'id =4' 인 작성자가 작성한 유일한 일정이기 때문이다.

일정 삭제 - 정상 요청

 

일정 삭제가 정상적으로 수행되면 별다른 응답 값을 반환하지 않도록 구현했다. 이 때, HttpStatus 는 '202 Accepted' 이다. 이제 DB 의 테이블들을 살펴보자.

일정 삭제 후, DB schedule 테이블(전체 목록)

 

'id =12' 인 일정의 정보가 잘 삭제된 것을 확인할 수 있다. 이제 'schedule' 테이블에 'author_id = 4' 인 일정은 없다. 다음으로 'author' 테이블을 확인해보면

일정 삭제 후, DB author 테이블

 

더 이상 작성한 일정이 없음에도 'id=4' 인 작성자 정보가 존재하는 것을 확인할 수 있다. 그렇다 나의 경우 작성자가 작성한 모든 일정이 삭제되어도 작성자 정보는 삭제되지 않도록 구현했다. 만약 작성자 정보를 삭제해야 한다고 하면 조건을 설정한 뒤, 혹은 작성자의 요청으로 작성자 정보를 삭제하는 기능을 추가할 것 같다.

 

생성되지 않은 일정을 삭제하려 한다면 '일정 조회' 와 같이 일정 정보를 조회하지 못했다는 오류 메시지가 반환되며, 비밀번호가 일치하지 않는 경우 '일정 수정' 과 같이 비밀번호가 일치하지 않는다는 오류 메시지가 반환된다.