TDD에 대한 얘기만 듣고 실제로 적용해본 적이 없어서, 손도 못대겠다 라고 생각했었다. Controller와 Service에서 단위 테스트와 통합 테스트에 대한 범위를 명확하게 인지하지 못해서 이틀정도는 서칭하고 강의 영상 찾아보는데 다 썼던 것 같다.
동시성 제어를 DB로만 해보다가 코드 레벨에서 할때 내가 실력이 너무 부족하구나…싶었다. Queue를 만들었는데, 한 테스트 안의 여러 요청에서 서로 다른 Queue에 담기면서 순차적으로 처리가 되지 않는 이슈가 있었다. 그리고 Queue에는 담았는데, 그럼 그거 나올때까지는 어떻게 기다릴건데…? 에 대한 고민들이 있었다.
2. 시도
강의를 들으면서 가장 심플한 예제를 보고 따라하면서 감을 잡는데 중점을 뒀다. 제일 쉬운 형태부터 하면서 익숙해지자. 그러면 할 수 있을 것 같았다.
Copilot 한테 가장 많이 물어봤다…Queue를 다룬다는 개념 자체를 물어보기도 하고, 그러다 감이 안잡혀서 다른 분들의 코드를 많이 들여다봤었다. 나랑은 다른 방식으로 접근하셨는데, 사실 이해를 못했다…
3. 해결
멘토링때 TDD는 리팩토링이 핵심이라고 해주셨다. Test 코드를 작성하고, 만족시키고, 리팩토링하고, 그에 따라 Test를 다시 변경할 것. 그래서 Controller Unit 테스트를 먼저 작성하고 Controller에 다 때려박았다…ㅎ 그 이후로 Layer를 하나씩 분리하면서 나아갔다. 한번에 해결하려고 하지 않고, 순차적으로 접근해나간게 느렸지만 오히려 명확했던 것 같다.
해결…못 했다…리뷰에서는 Queue를 가져오는 방식에 이슈가 있었을 것 이라고 하셨는데, 아마 설계 자체가 잘못되지 않았을까 생각한다.
4. 알게된 것
Test 코드가 큰 회사에서 코드 안정성을 위해서 일을 위한 일을 한다고 생각했었는데, 오히려 좋은 코드를 빠르게 작성하게 해주는 방식이라는걸 느꼈다. 비즈니스 로직을 짜는데 어떤걸 만족시키고 검증해야하는지가 명확했다.
mutex라는 패키지를 찾아보라는 리뷰를 받았다. Promise의 체이닝(?) 이라는 방식도 찾아보면 좋을 것 같다.