소개
안녕하세요 ☺️
몰입을 즐기는 개발자, 박우빈입니다.
- (현) 캐치테이블(와드) 소프트웨어 엔지니어
- (전) 우아한형제들 소프트웨어 엔지니어
- 우아한테크코스 3기, 4기 리뷰어 / 우아한테크캠프pro 1기 리뷰어
강의
전체1수강평
- 실무에 도움이 많이 되었습니다.
kopiuo
2024.05.16
0
- 과목이 어렵네요..
yunho_hwang
2024.05.08
0
- 테스트 코드 작성을 이해하기에 정말 좋아요 !
김수용
2024.05.02
0
- 감사히 잘 들었습니다.
김민종
2024.04.25
0
게시글
질문&답변
2024.05.17
a 서비스에서 b 서비스를 의존하는 코드에 대한 테스트는 어떻게 해야 되나요??
안녕하세요, 진짜 잘하고싶다 님! 하나씩 답변 드리겠습니다. 1. CommentService에서 다른 Service를 의존하게 되는 것 프로젝트의 아키텍처에 따라 달라질 수 있습니다만, 복잡도가 높아질수록 Service가 다른 Service와 협력하는 경우는 충분히 생길 수 있습니다. 2. 댓글 작성이라는 테스트를 짤 때 댓글 작성에 초첨을 맞출 수 없고 알림까지 테스트를 작성해야 되기 떄문에 핵심 기능 외에 다른 부가적인 기능 때문에 테스트의 집중도가 떨어집니다. 만약 두 서비스를 반드시 한 프로세스 내에서 검증해야 하는 것이 아니라면, 강의 중에 언급드리는 mocking을 사용하여 AlarmService에 대해 성공 혹은 실패 응답을 가정하고 CommentService의 테스트 코드를 작성할 수 있습니다. 3. 한 트랙잭션에 묶여서 알림을 생성하는데 문제가 발생하면 댓글도 생성되지 않습니다. 결국은 트랜잭션을 분리해야 하는 것이 맞습니다. '댓글'과 '알림'은 사실 전혀 다른 도메인인데요. 말씀하신대로 알림이 실패했다고 댓글 쓰기가 실패하면 안되기 때문에, 이 둘은 별도의 프로세스로 다뤄야 합니다. 당장 Service 레벨에서 적용을 고려해볼 수 있는 것은, 각 서비스가 각각의 트랜잭션을 가져가도록 하고, 트랜잭션의 전파 옵션(REQUIRES_NEW)을 고려해 보세요. ㅎㅎ 추가적으로, 대형 서비스의 경우 보통 댓글과 알림이라면 도메인이 아예 다르기 때문에 각각 별도의 시스템으로 구현합니다. 이런 경우, 두 시스템 간 데이터를 주고 받아야 할텐데요. 여러가지 방법이 있겠지만, 댓글과 알림은 반드시 실시간으로 동기화되어야 하는 도메인이 아니기 때문에(댓글에 대한 알림이 조금 늦게 온다고 사용자가 불편을 느끼지는 않기 때문에), 실시간 API call 보다는 이벤트 기반으로 동작하도록 하는 것이 효율적일 것입니다. 댓글 시스템에서 댓글이 생성되었다는 이벤트를 발행하면, 이를 SQS나 kafka같은 메시지 브로커에서 받아 대상인 알림 시스템에 전달해줍니다. 댓글 시스템에서는 이벤트 발행까지만 하면 댓글 쓰기에 대한 작업을 완료 처리할 수 있고, 알림 시스템에서는 발행된 이벤트를 받아서 무사히 알림을 발생시키기만 하면 되기 때문에, 두 시스템이 서로 간 의존성을 가지지 않고 동작할 수 있게 됩니다. 참고해 주세요 ㅎㅎ 도움이 되셨기를 바랍니다. 감사합니다. 🙂
- 0
- 1
- 37
질문&답변
2024.05.17
동시성 이슈 - 3회 이상 재시도를 자동으로 하게 하는 방법
안녕하세요, lch9502 님! 접근하신 방법이 맞습니다. 몇 가지 좀 더 말씀드리자면요. ㅎㅎ 테스트 코드를 통해 동시성 테스트를 할 수 있습니다. ExecutorService를 통해 스레드풀을 만들고 동시에 요청을 발생시키는 방법을 한번 찾아보셔도 좋을 것 같습니다 ㅎㅎ 위와 같은 재시도 방법의 경우, 비즈니스 플로우 상 크게 중요도가 높지 않은 케이스(즉, 3번 시도 후 실패해도 기능 상 중요하지 않거나, 사용자가 다시 요청을 하는 행위가 비용이 크지 않은 경우)에서 간단하게 시도해볼 수 있는 방법입니다. 만약 요청의 성공을 보장해야 하는 경우, 레디스 등을 활용한 분산락 같이 동시성 이슈를 해소하기 위한 여러가지 기법을 적용해볼 수 있으니 참고해 주세요. 도움이 되셨기를 바랍니다. 감사합니다. 🙂
- 0
- 1
- 54
질문&답변
2024.05.12
OrderRepositoryTest에서 단위테스트가 가능한가요?
안녕하세요, kksshh0612 님! 'productRepository와 관련된 코드가 들어가서 단위 테스트가 깨진다'는 표현과 문제 상황을 제가 잘 이해하지 못했습니다만, Order와 Product가 일대다-다대일 관계인데 각각 저장을 하기 때문에 문제가 발생하지 않나 라는 의미로 받아들였습니다. 우리가 given절에서 하는 일은 테스트하고자 하는 상황을 준비하는 것인데요, Order에 대한 테스트를 하기 위해서 필요한 내용은 Product를 생성하는 일과, 그 중간 매핑 테이블인 OrderProduct를 생성하는 일일 것입니다. 따라서, 강의 중 보여드린 것과 비슷하게 OrderProduct를 같이 만들어서 연관관계를 설정 후 저장해주면 크게 문제가 생기지 않을 것으로 생각되네요. 감사합니다. 🙂
- 0
- 1
- 49
질문&답변
2024.05.12
강의에서 나온 Service 레이어 테스트에 대해서 질문이 있습니당
안녕하세요, m3252 님! 1. 강사님은 classicist를 지향한다고 했는데, classicist의 단위 테스트는 데이터베이스와 같은 공유 의존성을 테스트 대역(mock)으로 대체해야 한다는 것으로 알고 있는데 유연한 사고(?)로 classist를 지향하지만 통합 테스트로 단위를 확인하는 것을 좋아한다 정도로 정리하면 좋을까요? 아니면 H2를 사용했으니 테스트 대역을 운영환경보단 빠른 환경으로 교체했으니 여전히 단위 테스트라고 생각을 하시는 걸까요? 음 이해하신 의미가 조금 반대인 것 같은데요. 간단하게 이야기해서 Classicist는 테스트 더블을 지양하고 최대한 실제 클래스의 유기적인 관계를 그대로 테스트하자는 입장이고, Mockist는 테스트 더블로 테스트하고자 하는 대상으로부터 다른 의존성을 모두 끊어내고, 정확히 테스트하고자 하는 부분만 떼어내서 테스트하자는 입장입니다. Service 테스트를 예로 들자면, 강의 중에 진행했던 것처럼 Service에서 사용하는 Repository(다만, 테스트 환경이니 경량화된 H2 DB로 갈음해서 사용)를 그대로 사용해서 테스트하는 것이 Classicist가 지향하는 바라고 볼 수 있겠고요. 만약 Mockist라면 Repository도 H2처럼 구동하는 실재가 아니라, FakeRepository라던가, mock 객체를 이용해서 흉내만 내는 테스트 더블을 사용해서 Service의 순수한 로직만 테스트했을 것입니다. 2. service 레이어를 통합 테스트로 안 짜는 팀에서 classicist를 지향한다면 DB에 대한 의존성을 어떻게 대체하는지 간단한 예제라도 보여주실 수 있을까요? ㅠ 질문이 잘 이해가 가지 않습니다..ㅎㅎ 통합 테스트를 안짜는 팀에서 classicist를 지향한다면 강의 중에 보여드린 방식처럼 H2를 사용한 스프링 통합 테스트를 작성해볼 수 있지 않을까요? :) 감사합니다. 🙂
- 0
- 2
- 79
질문&답변
2024.05.06
Mock과 Stub의 차이가 아직 잘 구분되지 않습니다.
안녕하세요, 송유현 님! 하나씩 답변 드리겠습니다. 1. 개인적으로 Mock은 상태를 (내가 작성한 값을) 반환하는 것 , Stub은 상태가 (내가 작성한 구현대로) 반환되는 것 이라고 정의를 내리고 있습니다. 이와 같은 표현으로 차이를 이해하고 있어도 괜찮을까요? 아니면 좀 더 명확한 표현이 있을까요? '값을 반환한다'와 '구현대로 반환된다'라고 하셨지만, Stub도 내가 구현한대로 값을 반환 하는 것에 초점이 맞춰져 있습니다. Stub은 테스트 검증을 위해 미리 지정해놓은 값을 반환합니다. 테스트할 기능 외에는 신경쓰지 않습니다. 반환된 값에 초점을 맞추어 검증합니다. Mock은 특정 행동을 지정하고, 테스트 과정에서 그 행동이 의도대로 이루어졌는지를 검증합니다. 정리하면, Stub은 상태 검증 , Mock은 행위 검증 의 시각으로 보는 것이 좋습니다. 2. Mock 객체에 우리가 원하는 행위를 정의(Stubbing)하면, 그 객체는 이제 Mock 객체라고 해야하나요 아니면 Stub 객체라고 해야하나요? Mock 객체에서 Stubbing을 정의할 수 있지만, 애초에 행위 검증을 위해 Mock 객체를 만들었다고 볼 수 있기 때문에 Mock 객체로 보는 것이 맞겠습니다. 사실 Mock 객체를 만들어서 어떻게 검증하는지까지 보아야 하는데, 만약 Mock 객체라고 만들었지만 검증 단계에서 값(상태)을 위주로 검증하고 있다면 사실 Stub 객체처럼 사용되었다라고 볼 수 있을 것이고, 객체의 행동에 대한 수행 과정을 검증하고 있다면 Mock 객체라고 이해하면 될 것 같아요. 3. 아래 코드를 보고 Mock 객체인 mailSendClient의 send 메서드에 대한 Stubbing이 이루어졌다. 라고 하면 맞는 표현인가요? 네, 맞습니다. when(mailSendClient.send(...)).thenReturn(true); 에서 특정 값을 반환하도록 설정(Stubbing)하였고, 검증 단계에서도 true 라는 값을 검증하고 있습니다. 추가적으로, 주석 처리되어 있는 verify(mailSendHistoryRepository, times(1)).save(any(MailSendHistory.class)); 는 값이 아니라 save() 메서드의 행위를 중심으로 검증하고 있기 때문에 mocking이라고 볼 수 있겠습니다. 4. mailSendClient는 Mocking하더라도 상태검증을 할 수도 있고, Stubbing하더라도 행위검증을 할 수도 있지 않나요? 이 둘의 차이는 Mockist와 Classicist의 차이이지, Mock과 Stub의 차이라고 할 수 없지 않을까요? Mocking/Stubbing과 Mockist/Classicist는 아예 다른 개념입니다. Mock 객체를 Stubbing하여 값 검증에만 쓰면 사실 Stub 객체처럼 사용하여 상태 검증을 한 것이고, 행위 검증을 한다면 Mocking했다고 할 수 있습니다. (즉, 객체를 생성해서 어떻게 검증을 하고 있는지까지 확인해보아야 합니다.) Classicist는 상태 검증인지 행위 검증인지, 어떻게 검증할 것인지에 대한 방법과 상관 없이, 정말 필요한 경우를 제외하고는 최대한 Mock 객체가 아닌 실제 객체를 사용 하여 검증해야 한다는 주장입니다. 즉, Mocking과 Stubbing은 테스트 도구의 사용 방법에 대한 개념이며, Mockist와 Classicist는 Mock/Stub과 같은 테스트 더블 자체를 주요 테스트 전략으로 사용하는 것이 더 나은지 아닌지를 이야기하는 테스트 철학에 관한 개념이기 때문에 전혀 다른 레벨로 이해하셔야 합니다. 도움이 되셨기를 바랍니다. 감사합니다. 🙂
- 0
- 1
- 110