[우테코 4기] 팀 프로젝트(공식) 개발 일지 - 인수테스트(1)

주리링·2022년 8월 2일
0

우테코 생존기

목록 보기
12/17
post-thumbnail

인수 테스트

인수 테스트란?

인수테스트(Acceptance Test)란 사용자 시나리오 테스트로 흔히 블랙박스 테스트라고 불린다.
블랙박스 테스트는 소프트웨어 내부 코드에 관심을 가지지 않는 테스트로, 개발자가 아닌 사람들도 보고 이해할 수 있어야하는 테스트다.

인수 테스트를 작성하며 생긴 고민

[Spring 지하철 노선도 - 3단계] 주디(윤주리) 미션 제출합니다. by jurlring · Pull Request #292 · woowacourse/atdd-subway-map

이전에 사용자의 입장에서 테스트 하는 것을 어떠냐는 리뷰를 받았었는데, 이 때 많이 깨닫게 되었다.

하지만 실제 개발에 들어가보니 생각과 다른 예외 사항들로 고민이 생겼다.

인수테스트를 작성하며 api문서를 보고 진행하고 있다.
이 때 create 테스트, read 테스트 이렇게 진행되고 있다.

이전에 받은 리뷰와 혼동되는 부분은 이전에는 사용자가 생성을 한 후에는 생성된 데이터를 확인하겠구나 라고 생각하고 생성 후, 조회를 하여 생성된 데이터를 확인했다.
이 때는 대부분의 생성된 데이터를 response로 보냈었다.
하지만 실제 프로젝트를 개발하다보니 성능적으로나(네트워크 리소스) 보안적으로나 좋지 않다고 판단되어 정말 필요한 정보만 내리게 개발하고 있다.

그렇다면 사용자 입장에서 생성 한 것을 확인하려면 조회를 해야한다고 생각이 됐다.
create테스트인데 read 테스트에 겹치는 내용 아닐까?
이 둘은 구분하지 않아도 되지만 같은 논리라면 update, delete 다 read을 해서 확인을 해야하는데 괜히 많은 리소스를 사용하는 것이 아닌가? 결국 모든 인수 테스트에 조회가 수반되는 것이니까.

팀원이 삭제하는 것을 꼭 눈으로 봐야 확인되는 것일까라고 물었는데 2가지 생각이 떠올랐다.

  • 확인해줘도 나쁘지 않은거 아닌가
  • 우리가 짠 로직을 못믿음?

어떤 건 확인하고 어떤건 확인 안하고 어떤 것을 확인해야한다는 것이 주관적이기 때문에 어느정도 컨벤션으로 잡혀있었으면 좋을 것 같다.

profile
코딩하는 감자

0개의 댓글