Update Technology Post " DDD 세레나데 7기 1주차 (feat. 이벤트 스토밍) "

- 3단계 미션에 대한 내용 추가 및 일부 링크 수정

Author: devFancy

_posts/2025-02-02-DDD-Week1-Review-And-EventStorming.md

@@ -92,7 +92,7 @@ author: devFancy
 
 1단계는 "문자열 덧셈 계산기"로 해당 주제에 맞게 코드를 작성하고 PR를 보내서 리뷰어분으로부터 코드 리뷰를 받게 된다. (해당 리뷰어의 PR 승인을 받게되면 미션을 완료했다는 결과이다)
 
-* 1단계에 대한 미션 요구 사항은 [1단계 요구사항](https://github.com/devFancy/ddd-legacy/blob/devfancy/1단계_요구사항.md) 에서 확인할 수 있다.
+* 1단계에 대한 미션 요구 사항은 [1단계 요구사항](https://github.com/devFancy/ddd-legacy/blob/devfancy/docs/1단계_요구사항.md) 에서 확인할 수 있다.
 
 1주차이고 해당 주제가 간단해서 그런지, 초반에는 세세한 부분 보다는 구현에 집중해서 PR를 제출했다. 하지만 리뷰어분의 피드백은 내 생각과 달랐다.
 
@@ -110,7 +110,7 @@ author: devFancy
 
 2단계는 해당 강의에서 수행하는 최종 미션 주제인 `키친 포스`에 대해 요구 사항을 작성하는 미션이다.
 
-* 2단계에 대한 미션 요구 사항은 [2단계 요구사항](https://github.com/devFancy/ddd-legacy/blob/devfancy/2단계_요구사항.md) 에서 확인할 수 있다.
+* 2단계에 대한 미션 요구 사항은 [2단계 요구사항](https://github.com/devFancy/ddd-legacy/blob/devfancy/docs/2단계_요구사항.md) 에서 확인할 수 있다.
 
 이번 2단계 미션에서 필자가 고민했던 부분은 '요구 사항을 어떻게 정리해야 하면 좋을까?' 였다.
 
@@ -130,6 +130,46 @@ author: devFancy
 
 * [[PR] 2단계 - 요구사항 정리](https://github.com/next-step/ddd-legacy/pull/790)
 
+### 3단계: 테스트를 통한 코드 보호
+
+> 추가한 날짜: 2025.03.15(토)
+
+3단계는 해당 강의에서 제공한 [ddd-legacy](https://github.com/devFancy/ddd-legacy/tree/devfancy) 프로덕션 코드와 2단계에서 필자가 작성한 `요구 사항`을 토대로 테스트 코드를 작성하는 미션이다.
+
+* 3단계에 대한 미션 요구 사항은 [3단계 요구사항](https://github.com/devFancy/ddd-legacy/blob/devfancy/docs/3단계_요구사항.md) 에서 확인할 수 있다.
+
+3단계에서는 Fixtures 클래스를 만들어서 활용했고, 매 테스트 실행 후 DB를 정리하기 위해 `tearDown()` 메서드를 적용했다.
+
+그리고 테스트 코드를 이전에 인프런 강의인 'Practical Testing' 에서 학습했는데, 해당 강의에서 배운 내용을 기반으로 적용하고자 했다.
+
+> 아래는 해당 강의에서 배운 내용을 개인 블로그에 정리한 글이다.
+
+* [Practical Testing: 테스트 코드 작성 방법](https://devfancy.github.io/Practical-Testing/)
+
+* [Practical Testing: 테스트 코드 작성 방법 - Mock, 더 나은 테스트를 위한 구체적 조언](https://devfancy.github.io/Practical-Testing2/)
+
+미션을 수행하는 도중에 궁금한 점들을 아래 PR를 통해 작성했고, 리뷰어님의 의견을 듣고자 했다. (리뷰어님이 나의 궁금한 점들을 최대한 구체적 + 경험에 비추어 답변해주셔서 정말 감사했다)
+
+* [PR 3단계 - 테스트를 통한 코드 보호](https://github.com/next-step/ddd-legacy/pull/835)
+
+리뷰어님의 피드백과 해당 강의에서 배운 결과, 테스트 컨테이너와 DB를 정리하는 `tearDown()` 메서드를 사용하는 것 보다 **테스트 시간이 짧은 인메모리로 `Mocking` 하고 `Fake` 객체를 사용하는 방법**을 택했다.
+
+테스트 컨테이너를 사용하면 매번 DB를 생성/종료하거나 데이터를 정리해야 하므로 실행 시간이 상대적으로 길어진다.
+반면 Mock/Fake는 DB 의존성이 없기 때문에 테스트가 가볍고 빠르며, 변경 사항을 자주 적용해야 하는 TDD 상황이나 대량의 테스트 케이스를 돌릴 때 빠른 피드백을 얻기에 훨씬 유리하다고 느꼈다.
+
+* 실제 DB 연결 없이 테스트 구동이 빨라진다. (네트워크 비용, DB 초기화 시간 소모 X)
+
+* 개발 환경에서 쉽게 세팅 가능하다.
+
+단, 단순한 비즈니스 로직이 아닐 경우에는 주의할 점도 있다.
+
+* 실제 DB와 달리, 인메모리에서 발생하지 않는 문제(복잡한 쿼리 최적화, 락 문제 등)가 숨겨질 수 있다.
+
+* 즉, "핵심 비즈니스 로직"은 Fake/Mock으로 빠르게 커버하되, "**DB 트랜잭션이나 복잡한 쿼리 로직 테스트**"처럼 프로덕션과 유사한 환경의 시뮬레이션이 필요한 경우에는 Testcontainers 등 실 DB 테스트도 추가로 진행할 수 있다.
+
+결국 테스트코드가 많아질수록 **테스트 실행 시간을 단축해야 하므로 인메모리를 적극 활용**해야 한다는 점을 배웠고, 
+**비즈니스에 중요한 부분**을 중심으로 테스트코드를 작성하는 것이 유지보수 관리에 드는 시간과 비용을 절감하는 데 효과적이라는 것을 이번 미션을 통해 다시 한번 깨달았다.
+
 ### 오프라인 모임: 이벤트 스토밍
 
 2월 1일 토요일에는 처음 오프라인 모임을 진행하게 되었다.
@@ -197,7 +237,6 @@ author: devFancy
 또한, 오프라인 모임에서 진행한 이벤트 스토밍을 통해, 단순히 기획 초기 단계에서만 활용하는 것이 아니라, 일정 수준의 기획이 진행된 후에 더욱 효과적이라는 점을 새롭게 배울 수 있었다. 뿐만 아니라, 이벤트 스토밍의 목적이 결과물을 만들어내는 것이 아니라, 
 참여자들이 도메인 지식을 공유하고 같은 이해를 가지는 과정 자체에 있다는 점도 깊이 와닿았다.
 
-아직 1주차 미션의 마지막 단계인 '테스트를 통한 코드 보호'도 남아 있지만, 다음 2주차 전까지 최대한 완성도를 높여 좋은 인사이트와 경험을 쌓고자 한다.
 
 ## Reference