대체 어떤 순서로 코드를 짜라는거야...
2주차 미션의 주제는 ATDD와 TDD였다. 즉 인수테스트를 작성하고 통과시키기 위한 기능 구현을 할 때 TDD 방식으로 구현을 해보라는 메세지의 미션이었다.
2주차 미션을 다 수행하고 여러 리뷰어의 의견 + 수업시간의 토론 + 구글링한 자료를 토대로 ATDD와 TDD의 나만의 사이클에 대해 정리하고자 한다.
여러 리뷰어의 추천 : 인수 테스트 > 도메인 테스트 > 서비스 테스트
인수테스트가 사용자 usecase 라고 볼수도 있을텐데요. usecase에서 필요한 도메인을 추출하고 그것을 바탕으로 도메인 테스트와 구현을 할 수 있을 것 같아요. 이렇게하면 말 그대로 인수 > 도메인 > 서비스 형태가 될 거에요.
-
인수테스트를 작성하면서 요구사항에 대한 흐름을 파악한다.
-
흐름을 파악한 뒤 필요한 도메인이 뭔지 도출해 낸다.
-
도메인 TDD를 하면서 기능 구현을 한다.
-
도메인이 완성되면 서비스 TDD를 하면서 기능 구현을 한다.
실제로 많은 4기 동기들이 이 과정 그대로 코드를 작성한 것을 볼 수 있었다.
이 방식은 Inside Out방식인 것 같다.
나의 추천 : Top-Down으로 방향을 잡고, Bottom-Up으로 구현
솔직히 2주차 강의에서 Top-Down으로 방향을 잡고, Bottom-Up으로 구현하라고 했을 때 이게 대체 무슨말인가... 싶었다.
그런데 구글링을 하던 중 이 말을 이해하게 도와준 자료를 발견하였다.
1. 디자인은 Top-Down으로
-
인수테스트를 작성하여 요구사항에 대한 흐름을 파악한다.
-> 도메인에 대한 지식이 부족하면 여기서도 도메인이 뭔지 도출을 못할 수 있다. -
서비스 테스트 코드에서 빈 테스트 케이스를 만들고 주석을 달며 서비스에는 어떤 기능이 있을지를 디자인 한다. (코드를 작성하지는 않는다)
-
위의 과정을 거치면 컨트롤러 ~ 도메인까지 어느정도 디자인이 된다.
2. 기능은 Bottom-Up으로
-
Top-Down으로 어느정도 디자인이 되었다면 도메인 TDD를 통해 도메인 기능을 구현한다.
-
도메인 기능이 구현되면 서비스 TDD를 통해 서비스 기능을 구현한다.
-
마지막으로 인수테스트에 검증기능을 추가하여 최종적으로 통과시킨다.
결국 리뷰어가 추천해준 방식이나 내가 추천하는 방식이나 비슷하다는 것을 알 것이다.
2주차 강의에서도 말했듯이 무조건 이 방식으로 해야 해! 이는 옳지 않은 생각이다.
그래도 이 강의에서 추천해준 방식에 나만의 방식을 더해서 이렇게 정리를 해 봤다.
앞으로 여러 미션이 남았는데 지금 이후로부터는 이 방식을 지키려고 노력하며 미션을 수행해봐야겠다.
