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