우아한 테크 캠프 PRO, 3주차 인수 테스트 주도 개발

우아한 테크 캠프 PRO, 3주차 과제 - 인수 테스트 주도 개발

• Step1 - 지하철 노선 관리
• Step2 - 인수 테스트 리팩토링
• Step3 - 구간 추가 기능
• Step4 - 구간 제거 기능

---

ATDD 도입 배경

상황

• 기존 TDD를 이용하여 레거시 프로젝트 리팩토링을 진행하려고 함
• 하지만 도메인에 대한 이해도 부족으로 인해 단위 테스트 작성이 어려움
• 객체 설계의 어려움으로 TDD Cycle 진행이 어려움 ( TDD 초보 기준... 잘하시는 분들은 뭘해도 잘하실듯 )

ATDD 방식 등장

• TDD의 단점을 보완하기 위해 인수 테스트(Acceptance test)를 먼저 구현한 후 이후 단위 테스트를 통해
  
  기능을 완성시켜 가는 과정으로 어플리케이션을 개발할 수 있다.

ATDD란?

• 개발 이전에 사용자, 테스터 및 개발자가 인수조건(Acceptance Creteria)을 정의하는 협업 실천법.
• 모든 프로젝트 구성원이 수행해야 할 작업과 요구사항을 정확히 이해할수 있도록 도와주는 테스트
• 실제 사용자가 하는 테스트, 어떤 식의 비즈니스 로직이 작동되고,

저장되고 등의 관심사의 테스트가 아닌 실제 사용자 입장에서 동작을 시켯을 때의 결과

FROM 위키피디아

Acceptance test–driven development (ATDD) is a development methodology based on communication
between the business customers, the developers, and the testers. ATDD encompasses many of the
same practices as specification by example (SBE),behavior-driven development (BDD), example-driven
development (EDD), and support-driven development also called story test–driven development (SDD).
All these processes aid developers and testers in understanding the customer's needs prior to
implementation and allow customers to be able to converse in their own domain language.

ATDD is closely related to test-driven development (TDD).
It differs by the emphasis on developer-tester-business customer collaboration.
ATDD encompasses acceptance testing, but highlights writing acceptance tests before developers begin coding.

ATDD Cycle

• ATDD 참고 문서

ATDD 작성 방법

• ATDD 작성 방법

Scenario: Forgot password

Given: The user navigates to the login page
When: The user selects <forgot password> option
And: Enters a valid email to receive a link for password recovery
Then: The system sends the link to the entered email
Given: The user receives the link via the email
When: The user navigates through the link received in the email
Then: The system enables the user to set a new password

• 하나의 테스트에 같은 도메인의 여러 상황을 담은 조건을 정의할 수도 있고, 각기 상황을 나눠서 테스트를 정의할 수 도 있다.
• 어플리케이션, 팀 컨벤션등의 종합적인 상황으로 판단하면 될 듯 하다.
• 개인적으로는 너무 복잡한 상황을 하나의 테스트에서 하려다 보면... 결국 한 싸이클 주기가 너무 길어지지 않을까하는 우려도 있다.
• 테스트가 관례적으로 영어 용어로 명확하게 이해시키지 못한다면 그냥 한글로 써라!!

RestAssured

• 인수 테스트을 하는 도구는 뭐가 정답이다 하는 건 없다. ( 의미와 테스트 커버리지가 중요하다고 생각하고 있음.. )
• 본 실습에서는 REST API의 테스트 및 검증을 단순화하도록 설계가 가능한 RestAssured 라이브러리를 소개한다.

미션 진행 회고

• 회사 프로젝트를 진행하면서 인수 테스트와 같은 End-to-End 테스트가 과연 필요한가? 라는 의문을 가지고 살았었다..
  
  테스트 시간이 너무 오래걸리고, 그냥 어플리케이션 올린 다음에 포스트맨 같은 걸로 테스트하면 되지않나?! 라는 생각을 했었다..
• 이번 강의를 듣고나서 위와 같은 생각의 전제 조건이 완전 달랐다는 것을 깨달음
• 인수 테스트는 완성된 어플리케이션의 테스트 커버리지로 적용되는 것이 아닌 요구사항을 프로젝트 개발하는 모든 사람들과 정의하는 역할을 한다.
• 물론.. 테스트 시간이 오래걸리긴 하기 때문에 인수 테스트와 기능 테스트 패키지를 분리해두면 빌드,배포등에서 유용하다고 강의자분께서 알려주심

피드백

• 인수 테스트에서 가독성은 매우 중요하다!! 의미있는 변수명을 나타내기 위해 한글로 쓰는 것도 좋다.
• 인수 테스트도 결국 코드이기 때문에 유지보수를 해야한다. 따라서 중복 제거, 불필요한 로컬 변수 지양 등의 기본 코딩 스타일은 지키자
• 객체 생성은 make* 보다는 create*가 더 관례적이다. ( 맨날 make로 쓰고있었음.. ㅠ )