오늘은 무슨 일이?
현재 미션에 TDD를 잘 모르고 적용하고, 핵심 비즈니스 로직에 대한 고민을 많이 하지 못한 상태로 1단계를 제출했습니다.
고쳐야할 것들이 많은데 테스트 코드 자체가 발목을 잡아서 프로젝트 전체를 뜯어고쳐야 하는 상황이 되었습니다.
사실 이전 미션들을 하면서 약간 자신감이 붙어서, 너무 고민 안하고 코드를 막 만들어낸 것 같아서 반성하게 되었습니다.
그래서 오늘은 리뷰 내용을 어떻게 고칠지 고민하고, 공부하며 하루를 지냈습니다.
공부한 내용 중에 오늘은 ATDD에 대해서 조금 공부해본 내용을 정리하였습니다.
ATDD
고객, 기획자, 개발자, 테스터 등의 직군들은 같은 작업도 서로 다른 시각으로 바라볼 수 있어서,
단순히 TDD만으로 각자 작업하여 결과를 확인하는 방식으로 제품을 개발하게되면 기대하지않은 결과물이 나올 수 있다고 합니다.
그래서, ATDD는 개발팀과 고객이 기획단계부터 함께 참여하여 공통된 목표를 설정하고 진행하는것이 중요하다고 합니다.
사용자 시나리오 작성→ 회의 →(테스트)허용 기준 설정→ 내용 정제 →인수 테스트 진행→ [개발] →제품 완성(소프트웨어)→ 데모 시연 →비즈니스 가치 창출
크게 위의 순서로 진행되는데, 인상적인 것은 일반적으로 마지막 단계에서 진행하는 인수 테스트를 제일 처음에 한다는 것입니다.
위는 v 모델 이라고 하는 소프트웨어 개발 프로세스 인데요.
일반적으로 가장 작은 단위인 단위 테스트 부터 진행하여 마지막에 인수 테스트를 하는 순서로 진행됩니다.
그런데 여기서 인수 테스트는 다른 테스트와 한가지 다른점이 있습니다.
그건 바로 단위 테스트, 통합 테스트, 시스템 테스트는 수주사의 주도로 테스트를 진행하는것에 반해인수 테스트는 고객 위주의 테스트를 진행한다는것 입니다.
ATDD의 핵심은 고객의 요구사항을 제일 먼저 테스트한다는 것입니다.
큰 그림을 먼저 그리고, 그 테스트가 완료가 되면 그 후에 개발 에 착수하게 됩니다.
그리고 개발 단계에서 자잘한 요소들을 TDD로 개발해 나가게 됩니다.
정리하면, TDD는 우리의 핵심 비즈니스 로직이 정상적으로 동작하는가를 확인하며 개발해 나가는 방식이라면,
ATDD는 고객이 원하는 기능이 이게 맞는지를 확인하고나서, 세부적인 기능은 TDD로 개발해 나가는 방식이라고 정리할 수 있겠습니다.
- 참고한 자료
- https://www.youtube.com/watch?v=uPgTvZO5laY
- https://www.youtube.com/watch?v=ITVpmjM4mUE
이 영상은 우아한테크세미나 영상인데 길어서 다 보지는 못했고, 조금씩 볼 생각.. - https://catsbi.oopy.io/319552ed-1536-4772-b039-8c6a7929bedc
토비의 스프링 1장을 읽고
저번주를 시작트로 틈틈히 토비의 스프링을 읽고 있습니다.
어렵고 읽기 힘들다고 주변에서 겁을 많이 줘서 겁을 많이 먹은채로(?) 읽기 시작했는데, 생각보다 읽을 만했습니다.
1장은 객체간 연관관계에 대한 고민을 하며 초난감 DAO라는 예제 코드를 리펙토링 해나가는 과정입니다.
관심사 분리, 인터페이스를 통한 느슨한 결합, 관계설정 책임의 분리 그리고 제어의 역전에서 오브젝트 팩토리,빈 팩토리, ApplicationContext, 싱글톤 빈, DI과 DL까지 아주 자연스럽게 이어집니다.
저자 토비님의 빌드업에 감탄을 하며 읽게 되었고, 간단히 정리한 내용은 여기에 정리했습니다.
이번 1장을 통해 객체지향을 탐구하다보면 결국 스프링으로 도달한다는 말이 왜 그런지 몸으로 느끼게 되어 너무 좋았습니다.
인상깊었던 점은?
- ATDD는 TDD의 방법론 중 하나인 줄 알았으나, 알고보니 더 큰 맥락에 적용되는 방법론이란 것을 알게되었음
- 스프링은 객체간의 연관관계에 대해 끊임없이 고민하다가 만들어진 프레임워크..!
아쉬웠던 것은?
- 공부만 한다고 미션 진행을 못했습니다.. 내일부터는 미션 진행 해보겠습니다!