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