인수 테스트 핥아보기

이 글은 필자의 이전 블로그인 https://velog.io/@beomdrive/NEXTSTEP-ATDD-1에서 핵심 내용을 중심으로 요약한 후에, 내용을 추가 보완하였습니다.

 

또 한번의 시작

퇴사 직후 바로 시작했던 Codesoom 멘토링 과정을 마무리하고 매우 고민이 됐었다.

• 코드숨 총 정리 - 8주간의 기록

더 채워가야 할 부족한 점이 뭘까?

 

물론 공부를 하면 할 수록 부족한 점이 계속 보이긴 했지만, 당장 급한 것이 뭘까 싶었다.
퇴사 후 지금까지 했던 공부들을 되돌아보면서 문득 생각이 들었다.

• "내가 진짜 테스트 코드를 효율적으로 짜는 역량이 생긴건가?"
• "내가 복잡한 비즈니스 로직에서도 코드를 클린하게 유지할 수 있을까?"

 

한동안 계속 고민을 하다가 멘토님이신 이동욱(향로)님께도 고민을 털어놓았더니 아래와 같은 조언을 해주셨다.

• "복잡한 비즈니스 로직에서도 클린하게 코드를 유지할 수 있는 연습을 해보는 것이 좋아요"
• "코드숨에서 진행한 미션들은 아쉽게도 비즈니스 로직이 그렇게 복잡한 부분은 보이지 않네요"
• "또한 코드숨에서는 Mock을 사용한 테스트 코드만 사용하신거 같은데, Mock 없는 테스트를 짜보시는것도 좋을 수 있어요"
• "CI/CD를 진행하는것도 좋지만 인프라쪽보다 우선시 되어야 할 것은 애플리케이션(코드)이라고 생각해요"

 

이런 조언들을 참고한 결과 NEXTSTEP의 ATDD, 클린 코드 with Spring 과정을 들어보자는 결론이 내려졌다.
해당 과정을 선택하게 된 계기는 다음과 같다.

• 복잡한 비즈니스 로직에서도 코드를 깔끔하게 유지하는 역량
• Mock 없는 테스트, 인수 테스트 등 다양한 테스트 전략
• 프러덕션 코드를 마음 편히 지지고 볶을 수 있도록 신뢰할 수 있는 테스트를 작성하는 역량

사실 Mock 기반 테스트는 코드숨 회고 글에서도 여러번 얘기했지만, 개인적으로는 신뢰가 많이 안가는 테스트 방식이라고 생각했었다.

따라서 Mock 없는 테스트 코드를 통해 신뢰성 있는 테스트 방식을 트레이닝하고 싶었기에 NEXTSTEP을 수강 할 것이다.

또 한번 열심히 달려나가서 효율적이고 다양한 테스트 전략을 습득하고, 복잡한 비즈니스 로직에서도 코드를 클린하게 유지하는 역량을 길러보자!

---

인수 테스트

첫 라이브 강의에서는 ATDD의 개념과 전반적인 프로세스, 인수 테스트 작성 방법 등을 학습하였다.

아래는 개념들을 학습하면서 머릿속에 정리하는 용으로 적어내려간 내용들이다.

 

ATDD

• 다양한 관점을 가진 팀원(기획, 개발, QA)들과 협업을 하기 위한 애자일 방법 중 한가지
• 기획 단계부터 인수 테스트를 통해 공통의 이해를 도모하여 프로젝트를 진행하는 방법
  
  • 모든 구성원이 결과물에 대한 싱크를 맞추고 작업에 착수하는 효과

 

ATDD 개발 프로세스

• 인수 조건 정의 → 인수 테스트 작성 → 문서화(RestDocs) → 기능 구현 → 테스트 리팩토링

 

인수 테스트

• 사용자의 관점에서 올바르게 작동하는지 확인하는 테스트
• 클라이언트가 의뢰 시 미리 전달했던 요구 사항이 모두 충족되었는지 인수 테스트를 통해 확인
• 인수 조건은 개발 용어가 아닌 일반 사용자들이 이해할 수 있는 단어를 사용하는 것을 권장

인수 조건 예시 : 매장 회원 수정

given : 매장을 등록하고
when : 기존 매장 정보와 수정할 정보를 가지고 회원 수정을 요청하면
then : 회원이 수정 대기 상태로 설정되고, 회원 정보가 수정된다.

 

 

BDD와 ATDD의 다른점

• BDD는 행동 기반 테스트로 기능의 동작에 더 중점을 둠
• ATDD는 정확한 요구 사항을 포착하는데 중점을 둠