Book-Crew 라는 기술서적을 읽고, 서로 리뷰하고 모르는걸 찾아보면서 공부하는 스터디를 진행하고 있는데, 스터디원중에 한분께서 Next Step을 추천하셨고, 정말 많은 도움을 얻었다고 들었다.
이번 교육의 일정은 아래와 같다.
📻 교육일정
교육 기간은 2024-01-22(월) ~ 2024-02-29(목) 입니다. 교육기간 동안 온라인 강의는 라이브로 진행될 예정이며 교육기간 중 매주 목요일에 5회 진행됩니다. 첫 강의 전에 교육이 시작되는 이유는 사전 미션 및 강의 수강 준비를 위해서입니다.
1월 25일: 1주차 강의
2월 1일: 2주차 강의
2월 3일: 모짝미(모여서 짝 프로그래밍 미션)
희망자에 한해서 오프라인으로 모여서 페어 매칭 후 미션 진행, 참여 여부는 추후 받을 예정
2월 8일: 강의 없음
2월 15일: 3주차 강의
2월 22일 : 4주차 강의
2월 29일 : 5주차 강의
온라인 강의는 매주 목요일 오후 7시 30분에 강의를 시작하고, 류성현(우아한 형제들)님께서 맡아서 3월까지 진행하고 있다.
🎈 강의시작
1주차 강의에서는 4가지를 말했다.
과정소개
인수 테스트
인수 테스트 만들기
미션 소개
우선 TDD를 활용할 때 어려움을 겪었다면 그 이유는 무엇인지를 물어봤는데,
확신 & 경험부재
방법
해야하는 이유(왜 하는지 모르겠다, 동료를 이해시키기 어려움)
요구사항 및 도메인 이해
위와 같은 답변들이 나왔다.
나 같은 경우는 "TDD가 너무 유행처럼 왔다~ 라는 소리도 들었고 A,B,C도 모르면서 하려하냐~ 이런것도 있던 것 같아요" 라고 했지만, 하나하나 아닌 이유에 대해서도 말씀해주셨다.
TDD가 어렵다고 느끼는 이유는 웹 애플리케이션의 특성이 의존성과 복잡도가 가중되어서 테스트 만드는 것 부터 어려워지고 통합하기도 어렵기 때문이라고 말했다.
하지만 TDD를 해내도 확신이 없는데, "이게 맞나?" 라는 생각이 들텐데 기능이 잘 동작하지 않은 경우나, TDD를 했지만 최초 의도한대로 기능 개발이 안 된 경우 때문에 그렇다고 말했다.
이건 그 결과적으로 => 쉽지 않네, 어렵네, 안하는게 더 좋아 로 이어진다.
❓ TDD 잘하는 방법
그럼 어떻게 TDD를 어떻게 하면 잘 할수 있을까?
답은 바로 인수 테스트다.
인수 테스트를 통해 TDD만을 하는데 생기는 문제를 방지 할 수 있다. (TDD + 인수테스트)
이 과정의 목표는 5가지인데
E2E 테스트 기반의 인수 테스트 작성 경험
인수 테스트 기반 웹 API 기능 구현 경험
웹 프로젝트 레벨 TDD 경험
스프링 기반 테스트 도구 학습
코드 리뷰 프로세스 경험
기대 효과는 아래와 같다.
인수 테스트 기반 TDD를 할 수 있다
테스트를 효과적 리펙터링하여 유지보수를 잘 할 수 있다
새로운 프로젝트 뿐 아니라 레거시에도 TDD를 할 수 있다
남들에게 TDD와 ATDD가 실무에서 가능하다고 설명할 수 있다.
이런 목표를 이루기 위해서는 하나라도 테스트를 더 짜보고, 한번이라도 더 타자를 쳐 보는것이라고 한다.
1주차는 인수테스트
2~3주차는 인수테스트 + TDD를 다루는 과정
4주차는 인증 기반 인수 테스트
5주차는 리펙터링 with 인수테스트(Cucumber)
NextStep과정은 아래와 같은 사이클로 이루어진다.
기능구현만이 미션의 목적은 아니다.
미션을 먼저 수행하고, 피드백과 코드리뷰를 받는다. 그리고 강의를 통해 놓쳤던 부분을 다시 한번 체크한다.
물론 미션을 수행하고, 리뷰를 받고 다시 한번 코드를 작성하고 다시 리뷰를 받는 과정이 있다.(횟수는 제한없음)
😊 슬기롭게 임하는 방법!
OT나 강의 초반에 과제 양이 꽤 된다.
그래서 대충 듣고 미션 한두시간 하면 절대 안된다. 1~2시간 해도 되지만 그건 매일 해야한다.
몰아서 주말에 하는건 불가능하고 1주일에 최조 4회 이상 코드리뷰 요청을 보내 코드 리뷰 받기 최소 하루에 2시간 이상 투자!
정답을 찾기 위해 집착하지 말기
미션 진행에 정답은 없다
정답을 찾으려는 노력이 오히려 더 학습을 방해한다
현재 상황에서 최선의 답을 끊임없이 찾으려 노력한다 ==> 싸이클을 반복하면서 ATDD와 TDD를 학습하기 위한 것
리뷰어 피드백 상반되는 경우에는 혼란스러워 말고 그 이유에 대해 생각하고 질문하면서 즐기자!
ATDD? TDD를 하기 위한 인수테스트
인수테스트란? Acceptance Test다.
사용자 스토리를 검증하는 기능 테스트이며 사용자 스토리로 테스트 할 시나리오를 지정
즉 명세나 계약의 요구 사항이 충족되는지 확인하기 위해 수행하는 테스트를 인수테스트라고 한다.
보통 마지막 단계에서 수행하는 테스트를 의미한다.
이 과정에서는 작업을 종료 시켜도 되는지 검증하는 테스트고, 이 테스트가 끝나면 기능 구현이 완료된 것이다.
하지만 보통 인수 테스트란 아래와 같은 모든 테스트를 인수 테스트라고 할 수도 있다. 명확히 정의된건 없다.
하지만 이 교육과정에서는 E2E테스트(End to End)를 인수테스트라고 정의한다.
테스트의 종류
단위 테스트
통합 테스트
E2E 테스트
요구사항이 있을 때 가장 먼저 뭘 해야할까? 가장 먼저 시나리오 형태로 요구사항을 바꿔본다.
로또 프로젝트라면
만원을 입력한다
10장의 로또가 구매된다
구입한 로또 번호가 출력된다
지난주 당첨 번호로 1,2,3,4,5,6을 입력한다
당첨 통계가 출력된다
수익률이 계산된다
이 상태로 변경이 가능하다.
그럼 시나리오 형식으로 변경이 된다면 뭘 해야할까?
시나리오 형식으로 변경을 하게 되면 어떤걸 구현해야 할지 명확하게 보이게 되고, 누가 개발해도 비슷한 flow가 형성이 될 것이다.
그리고 정상적인 시나리오가 있으면, 비정상적인 시나리오도 정의해야한다.
시나리오를 정의하면 간단한 비정상적 테스트 부터 작성하고, 그 이후 정상적인 시나리오를 기반으로 개발을 해야한다.
📎 요약해보자
1.요구사항을 받는다.
2.시나리오 기반으로 요구사항을 변경한다.
→ 이후에 domain 설계, ERD 등을 설계한다.
3.비정상적 시나리오를 만든다.
4.비정상적 시나리오 테스트를 먼저 만든다.
5.정상적 시나리오 테스트를 만든다.
6.API를 구현한다.
이 과정을 한단계씩 짚고 넘어가는게 공부할때 좋겠지만, 실제 익숙해질 때는 3,4,5를 모든 시나리오를 검증하지 않거나, 중요한 시나리오만 검증하는 등의 싸이클이 필요하다.
그럼 인수테스트는 API 테스트인지? E2E인지? 통합인지? 인수테스트는 의도에 따라 달라진다.
인수테스트는 시나리오를 검증하는 테스트기 때문에 개념이 모호하다.
그렇기 때문에 "테스트를 어떻게 구현하는지에 따라 정해지는 것이 아니다."
(린 애자일 기법을 활용한 테스트 주도 개발 中)
이번 과정에서는 백엔드 개발자가 단독적으로 적용해서 실천해볼 수 있는 범위, API 접점에서 검증하는 E2E 테스트를 인수테스트라고 할 것이다.
API의 Req, Res 이외의 내부 정보는 최대한 가리는 블랙 박스 형식의 테스트다.
왜 restAssured인가?
취향의 문제지만, 이번 과정에서는 restAssured를 선택한 것이다.
왜 이걸 골랐냐면 SpringBootTest의 webEnvironmnet속성중에 MOCK을 사용해서 MockMvc를 이용할 수 있는데, 내부적으로 mocking된 환경이 아닌 실제 웹 환경을 통해 테스트를 구성할 수 있기 때문에 thread도 실 환경과 동일하게 동작한다.(Transaction도 동작함) 또한 사용성이 가장 뛰어났다.
그리고 추후 다른 서버의 테스트 또한 가능하기 때문에 이걸 선택했다고 한다.
TDD 특성상 개발 시간이 많이 드는건 어쩔 수 없는건가?
TDD가 익숙해지면 더 빨라지기도 하는지? => 개발이란 행위를 단지 코드작업으로 한정짓는지, 아니면 정상동작 하는지 나머지 시간까지 개발 시간으로 합친다면 크게 차이가 나지 않는다. 라고 한다. 하지만 단순히 코드를 짠다는것만 말하면 당연히 TDD를 하는게(테스트코드를 짜지 않는 시간에 비해) 시간이 더 많이 든다.
하지만 전체적으로는 손수 테스트를 해야하고 내가 짠 코드를 불안해하지 않는다는 측면에서 이득이 있다.
