소개
안녕하세요 ☺️
몰입을 즐기는 개발자, 박우빈입니다.
- (현) 캐치테이블(와드) 소프트웨어 엔지니어
- (전) 우아한형제들 소프트웨어 엔지니어
- 우아한테크코스 3기, 4기 리뷰어 / 우아한테크캠프pro 1기 리뷰어
강의
전체1수강평
- 과목이 어렵네요..
yunho_hwang
2024.05.08
0
- 테스트 코드 작성을 이해하기에 정말 좋아요 !
김수용
2024.05.02
0
- 감사히 잘 들었습니다.
김민종
2024.04.25
0
게시글
질문&답변
2024.05.12
OrderRepositoryTest에서 단위테스트가 가능한가요?
안녕하세요, kksshh0612 님! 'productRepository와 관련된 코드가 들어가서 단위 테스트가 깨진다'는 표현과 문제 상황을 제가 잘 이해하지 못했습니다만, Order와 Product가 일대다-다대일 관계인데 각각 저장을 하기 때문에 문제가 발생하지 않나 라는 의미로 받아들였습니다. 우리가 given절에서 하는 일은 테스트하고자 하는 상황을 준비하는 것인데요, Order에 대한 테스트를 하기 위해서 필요한 내용은 Product를 생성하는 일과, 그 중간 매핑 테이블인 OrderProduct를 생성하는 일일 것입니다. 따라서, 강의 중 보여드린 것과 비슷하게 OrderProduct를 같이 만들어서 연관관계를 설정 후 저장해주면 크게 문제가 생기지 않을 것으로 생각되네요. 감사합니다. 🙂
- 0
- 1
- 26
질문&답변
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
- 57
질문&답변
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
- 97
질문&답변
2024.05.06
@SpringBootTest 여러 개 사용 시 데이터 남아있는지 여부 문의
안녕하세요, korn79 님! AI 인턴이 저보다 먼저 답을 잘 해주었네요. ㅎㅎ 데이터는 롤백되는 것이 맞지만, DB 레벨에서 제공하는 ID의 자동증가 값은 트랜잭션 롤백과 무관하게 계속 증가됩니다. 따라서 이런 테스트를 작성할 때에는, ID의 값이 얼마다(ex. id가 1이다)라고 검증하기 보다는 그 외 비즈니스 키(해당 객체를 식별할 수 있는 키)로 내가 조회한 데이터가 예상한 데이터가 맞는지 검증하는 것이 좋습니다. 도움이 되셨기를 바랍니다. 감사합니다. 🙂
- 1
- 2
- 61
질문&답변
2024.04.22
강사님 유효성 검증의 분리에 대해 궁금한점이 있습니다.
안녕하세요, 두잇베스트 님! 패스워드를 예시로 들어주셨는데, 패스워드 같은 경우는 도메인에 따라, 바라보는 시각에 따라 어디서 검증할지가 달라질 수 있는 예시일 것 같아요 ㅎㅎ 해당 API가 담당하는 도메인 로직에서 패스워드 검증 룰 자체가 중요한 역할을 차지하고 있다면 도메인 쪽에서, 그렇지 않다면 '영문/특문 혼합 8자리' 라는 룰은 앞단에서 검증하고 끝내도 된다고 생각합니다. 이럴때는 앞단에서 검증하고, 저럴때는 뒷단에서 검증해라, 와 같이 답이 정해져 있는 문제는 아니어서 상황에 따라 어느 쪽에서 검증하는 게 좋을지 판단하시면 됩니다. 강의 중 의도는 '아무리 단순한 검증 로직이어도, 중요한 도메인적 의미를 담고 있다면 도메인 레이어에서 검증하면서 그 규칙을 지속적으로 관리할 필요가 있다'는 것이었어요. 도움이 되셨기를 바랍니다. 감사합니다. 🙂
- 0
- 2
- 104