[NEXTSTEP] ATDD 과정 1주차 시작

https://edu.nextstep.camp/c/R89PYi5H

ATDD, 클린 코드 with Spring

 

 

2023-06-26(월) ~ 2023-08-09(수) 의 기간 동안 넥스트스텝에서 진행하는 인수테스트 수업을 수강한다.

이번 기수가 7기인 만큼 해당 과정에 대한 소개나 학습 리뷰는 많은 부분 구글에서 찾을 수 있기 때문에 나는 내가 정리한 내용과 미션을 진행하며 작성한 코드, 생성한 PR, 리뷰어에게 받은 피드백과 대화를 기록하는 용도로 글을 작성하려 한다.

 

넥스트스텝의 강의들은 우아한 형제들의 개발자이자 교육자가 만들고 진행하는 교육이기 때문에 퀄리티가 매우 높다.

정답을 주입하는 방식이 아닌 과정을 진행하며 학습자가 스스로 성장하고 지평을 넓혀 자신을, 동료를, 더 나아가 세상을 이롭게 하는 것을 목적으로 한다.

 

자바지기 == 포비 == 박재성 님의 교육 이념은 가히 존경할만 하다.

 

---

과정을 슬기롭게 임하는 방법 - 주변 환경을 정리해 꾸준히 연습할 시간 확보

• 환경 바꾸기
  • TV를 보지 않는다
  • 스마트폰을 보는 시간을 줄인다.
• 시간을 확보하기
  • 퇴근 후 카페로 출근한다
  • 야근을 하지 않는다
• 여러분의 의지력을 믿지 마세요. 환경을 바꾸세요.

매일 1~2시간씩 미션 진행하기

• 한번에 모두 구현하기 보다 매일 일정한 시간 투자하는 것이 정말 중요함
• 일주일에 최소 4회 이상 코드리뷰 요청을 보내 코드 리뷰 받기
• 최소 하루에 2시간 이상 투자해야 미션을 완료할 수 있었음

리뷰어 피드백이 상반되는 경우

• 상반되는 의견에 혼란스러워하지 말고 즐기기
• 상반되는 의견에 대해 생각할 수 있는 계기로 생각하기
• 마음껏 생각하고 자신만의 프로그래밍 색깔을 만들기
• 앞선 피드백과 다음 피드백이 상반 될 경우에는 바로 받아들이기 보다는 리뷰어에게 DM을 보내 경험과 의견을 공유하며 피드백을 추가로 얻고 생각의 확장을 하자

지우고 다시 해보기

• 미션의 목적은 기능 구현이 아니라 TDD Cycle 실습 및 경험
• 같은 기능이라 하더라도 두번째 구현할 때는 다른 Cycle을 경험 할 수 있음
• 도메인과 기능에 대한 이해도에 따라 달라지기 때문

정답을 찾기 위해 집착하지 말자

• 미션을 진행하는데 정답은 없다
• 정답을 찾으려는 노력이 오히려 학습을 방해한다
• 현재 상황에서 최선의 답을 끊임없이 찾으려고 노력한다

강의에서 배운 그대로 하지 마세요

• 강의를 통해 여러분의 지평을 넓혔으면 넓힌 그 영역은 질문으로 채우기
• 강의를 듣고 질문이 생겨서 그 질문의 답을 유추해 가는 과정이 필요

단위테스트

• 개발자 친화적으로 어떻게 구현한지 잘 동작하는지 확인하는 목적

인수테스트

• 시나리오 형태의 기획자의 요구사항이 의도한대로 동작하는지 확인하는 목적

인수테스트 주도 개발을 하는 이유

• 생산성 증가
  • 구현 전에 인수테스트를 수행하는 경우 팀의 생산성이 두 배가 되는 것을 확인했다 - 제프 서덜런드(스크럼 공동 제작자)
  • 공통 이해 상황 아래서 개발이 진행 되기 때문에 기획 → 개발 → 검증 → 기획 → 개발의 불필요한 반복을 줄일 수 있다.
• 작업의 명확한 시작과 끝을 제시
  • 인수 테스트의 사이클이 끝나는 순간 요구사항을 모두 작업했다는 것이 보장 됨
  • 어떠한 문서보다 동작하는 테스트로서 보장이 됨
• TDD의 부족한 부분을 보완 할 수 있다.
  • 단위는 잘 되었는데 통합 테스트에서 안되는 경우가 생길 수 있음
  • 전체적인 시나리오를 놓치게 되는 경우가 생기지만 이를 보완 할 수 있음
• 빠른 피드백
  • 구현한 기능을 배포하지 않고 테스트만으로 실제로 동작하는 시나리오를 확인 할 수 있음
  • 실제 배포 후 확인보다는 부족할 수 있지만 자동화 가능
• 귀찮은 작업이 프로세스로 강제 됨
  • 테스트 코드 작성과 문서화는 귀찮은 작업이지만 전체 기능을 검증하는 테스트를 만들면서 동시에 회기 테스트 역할을 수행하게 됨
    • 회귀 테스트 : 이미 테스트 된 프로그램의 테스팅을 반복하는 것으로, 결함 수정 이후 변경의 결과로 새롭게 만들어 지거나 이전 결함으로 인해 발견되니 않았던 또 다른 결함을 발견하는 테스트
  • 테스트와 문서 작성하는 것을 별도의 이슈로 가져가게 되면 우선순위에서 계속 밀리게 됨

기획자, QA와 함께 러프한 기획서를 갖고 인수조건들을 정의하고 이를 모두 동의한 상태에서 인수 조건을 토대로 개발을 하는 방식으로 한 사이클이 가능함

 

Acceptance Test in extreme programming

• 사용자 스토리를 검증하는 기능 테스트
• 사용자 스토리로 테스트할 시나리오를 지정

Acceptance Test in real world

• 명세나 계약의 요구사항이 충족 되는지 확인하기 위해 수행되는 테스트
• 소프트웨어 이외 다른 분야에서도 사용 되는 용어
• 보통 마지막 단계에서 수행하는 테스트를 의미
• 작업을 종료시켜도 되는지 검증하는 테스트
• 이 테스트가 성공하면 작업 끝

테스트 주도 개발로 배우는 객체 지향 설계와 실천

• 인수 테스트가 통과되면, 기능 구현은 끝이다.

테스트 종류

• 단위 테스트
• 통합 테스트
• E2E 테스트
• api 테스트
• 시나리오 테스트

보통 테스트가 검증하는 대상, 방법으로 테스트 이름을 정하게 됨

인수 테스트는 그럼 API, E2E, 통합 중 뭘까?

• 단위 테스트는 구현한 부분, 단위를 검증
• 통합 테스트는 각 단위들이 유기적으로 잘 동작하는지 검증
• 인수 테스트는 요구사항을 만족하는지를 검증
• 인수 테스트의 개념은 테스트 의도에 따라 정해지는 것이지 테스트를 어떻게 구현하는지에 따라 정해지는 것이 아니다. 유닛 레벨이나 통합

 

레벨, 사용자 인터페이스 레벨에서 인수 테스트를 적용 할 수 잇다.

더 나아가 인수 테스트를 유닛이나 컴포넌트가 의도한 동작을 하는지 확인하는 설계 검증 테스트로 사용할 수 도 있다.

어떤 경우든 인수 테스트는 사용자에게 애플리케이션이 인도 될 수 있는지를 확인한다.

 

이번 과정에서의 인수테스트

• 백엔드 개발자가 단독적으로 적용해서 실천해 볼 수 있는 범위
• 고객은 프론트엔드 개발자 혹은 API를 활용하는 사람
• API 접점에서 검증하는 E2E 테스트
• API의 요청과 응답 정보 외의 내부 정보는 최대한 가리는 블랙박스 형식의 테스트

인수 테스트 만들기 - 테스트 만들기 전 알아야 할 것

• 블랙 박스 테스트
  • 인수 테스트는 블랙 박스 테스트의 성격을 가지고 있음
  • 블랙박스?
    • 클라이언트는 결과물의 내부 구현이나 사용된 기술을 기반으로 검증하기 보다는 표면적으로 확인할 수 있는 요소를 바탕으로 검증하려 함
    • 실제 사용하는 상황의 시나리오를 바탕으로 요구사항을 작성
    • 내부 구현이나 기술에 의존적이지 않는 블랙 박스 테스트
• E2E테스트
  • API 레벨의 블랙박스 테스트이므로 요청과 응답 기준으로 API를 종단하는 테스트
• 클라이언트와 서버의 요청과 응답

728x90

---

 

https://google.com으로 get 요청을 보내 200 ok를 받는지 검증하는 RestAssured를 활용할 수 있는지를 확인하는 

0단계 미션

test : verify 200 ok response when request get google index page by ktae23 · Pull Request #767 · next-step/atdd-subway-map

 

Station이란 도메인의 생성, 조회, 삭제 요청에 대한 검증을 하며 RestAssured를 활용한 요청의 재사용을 위한 메서드 분리 등의 리팩터링을 확인하는 1단계 미션

나는 여기서 한단계 더 나아가 @AcceptanceTest 를 만들어 테스트 설정을 한곳으로 모으고 AcceptanceTestBuilder를 구현하여 RestAssured의 여러 설정, 특히 log().all()과 같은 부분을 숨겨서 더욱 given, when, then에 집중 할 수 있도록 했다.

 AcceptanceTestBuilder
            .given()
            .when(HttpMethod.GET, RESOURCE_URL)
            .then(HttpStatus.OK)
            .body("", hasSize(2))
            .body("[0].name", equalTo(firstStationName))
            .body("[1].name", equalTo(secondStationName));

하지만 이번 미션의 목적은 메서드 분리를 통한 재사용성 확보의 목적도 있었기 때문에 분리를 진행했다.

팩터리 클래스를 사용하고 멀티 타입 빌더를 통해 각 타입별 생성과 메서드 체이닝 제한을 두고 싶었지만 사실 스프링 시큐리티나 RestAssured만큼 해낼 자신도 없고 학습 목적에서 벗어난 부분이라 하지 않았다.

🚀 1단계 - 지하철역 인수 테스트 작성 by ktae23 · Pull Request #819 · next-step/atdd-subway-map

 

나중에 또 글을 작성할 일이 있겠지만 현재 회사에서 핵심 도메인에 대한 대규모 리팩터링을 주도 하고 있고 7월부터는 한 교육과정에 멘토로 참여하게 되어 매우 바쁜 나날을 보낼 예정이다.

동시에 이 과정에도 소홀하지 않으며 많은 것을 배워가고 싶기 때문에 욕심을 부려본다.