[4주차]

섹션7

• Mockito로 Stubbing하기

  • 외부 서비스를 테스트하려면 실제로 수행하거나, Mocking하여 가짜 객체를 만들어서 사용

  • Mocking하여 Mock 객체의 응답을 정해줌으로써, 외부 서비스와의 독립성을 유지

  • 외부 서비스가 있어도 간단하게 서버 로직에 대한 검증 가능

• Test Double

  • Dummy : 아무것도 하지 않는 깡통 객체

  • Fake : 단순한 형태로 동일한 기능은 수행하나, 프로덕션에서 쓰기에는 부족한 객체

  • Stub : 테스트에서 요청한 것에 대해 미리 준비한 결과를 제공하는 객체 그 외에는 응답하지 않는다.

  • Spy : Stub이면서 호출된 내용을 기록하여 보여줄 수 있는 객체, 일부는 실제 객체처럼 동작시키고 일부만 Stubbing할 수 있다.

  • Mock : 행위에 대한 기대를 명세하고, 그에 따라 동작하도록 만들어진 객체

  • Stub -> 상태 검증, Mock -> 행위 검증

• @Mock, @Spy, @InjectMocks

  • Mock은 정해진 행위를 하는 객체를 만드는 것

  • Spy는 실제 객체의 메서드를 수행하지만, 특정 메서드만 mocking한 것

  • InjectMocks는 Mock과 Spy 객체를 자동 주입해주는 것

• BDDMockito

  • 행동주도개발

  • TDD -> when().thenReturn(), BDD -> given().willReturn()

• Classicist VS Mockist

  • Classicist : Mock을 통한 검증은 완전함을 보장할 수 없다.

  • Mockist : Mock을 통해서 각각 테스트를 성공했으면 된다.

섹션 8

• 한 문단에 한 주제

• 완벽하게 제어하기

  • 현재 날짜, 현재 시간 등 제어할 수 없는 값은 파라미터로 넘겨서 상위 계층에서 관리

• 테스트 환경의 독립성을 보장하자

  • 테스트가 실패하는 부분은 when절 또는 then절이어야 한다. given 절에서 실패하면 안된다.

  • given 절에서 객체를 생성할 때는 순수한 생성자 또는 builder 기반으로 만들면 좋다.

• 테스트 간 독립성을 보장하자

  • 테스트 간 공유 자원을 사용하면 안된다.

  • 공유 자원을 사용하면 테스트 간 순서에 따라 성공, 실패가 갈린다.

• 한 눈에 들어오는 Test Fixture 구성하기

  • @BeforeEach를 사용하여 설정할 경우, 각 테스트 입장에서 봤을 때, 아예 몰라도 테스트 내용을 이해하는데 지장이 없어야 한다.

  • 뇌의 메모리를 적게 사용

• Test Fixture 클렌징

  • deleteAll, deleteAllInBatch

• @ParameterizedTest

  • enum 클래스의 각 값에 대하여 테스트를 하고 싶을 때, ParameterizedTest를 수행하면 좋다.

  • ValueSource() 파라미터가 1개일 때

  • NullSOurce, EmptySource, NullEmptySource

  • CsvSource() csv 형식으로 여러개의 파라미터 사용

  • 여러 개의 파라미터 값을 테스트하고 싶을 때 사용

• @DynamicTest

  • 한 문단에 한 주제, 하지만 연속된 상황을 검증하고 싶다면?

  • 연속된 상황을 부여하여, 일련의 시나리오를 테스트할 수 있다.

• 테스트 수행도 비용이다. 환경 통합하기

  • 테스트 환경이 달라지면, 서버가 각 테스트 클래스마다 새로 부팅한다.

  • 통합 테스트 클래스를 만들어서, 통합 테스트 클래스가 실행될 때 1번 서버가 실행되도록 한다.

  • MockBean, SpyBean 등 환경이 달라지면 통합 테스트 클래스를 상속받아도 서버가 새로 부팅된다.

  • MockBean, SpyBean을 통합 테스트 클래스에 옮겨놓으면 1번으로 유지 가능

  • DataJpaTest를 repository 테스트를 할 때 쓴다면 이것도 환경이 달라졌으므로, 서버를 새로 부팅

  • WebMvcTest, SpringBootTest, DataJpaTest 각각 통합 테스트 클래스를 만들어주면 3번만 부팅

• private 메서드의 테스트는 어떻게 하나요?

  • private 메서드는 테스트할 필요 X

  • 외부로 노출되지 않는 기능까지는 알 필요가 없다.

  • 단위 테스트 검증 시에 어차피 검사하게 된다.

  • 그래도 하고 싶다면, 객체 분리를 통해서 public으로 만든 후 검증

• 테스트에서만 필요한 메서드가 생겼는데 프로덕션 코드에서는 필요 없다면?

  • 만들어도 되지만, 지양하자

[회고]

벌써 마지막 주차가 되어버렸다. 1달 동안 클린코드와 테스트코드에 대해 전혀 무지했던 내가 개념을 익히고 실습을 하며

어떻게 하면 더 깔끔하게, 더 읽기 편하게 적을 수 있을까를 고민하게 되었고, 어떻게 검증해야 할까, 무엇을 검증해야 할까를 고민할 수 있게 되었다.

1달이라면 길다면 길고, 짧다면 짧은 시간 동안 한층 더 나아갔고, 더 우수한 사람이 되기 위해 노력했다. 한달 전의 나보다 성장했기에 뿌듯하고, 앞으로 성장할 나를 위해 다시금 노력하자

워밍업 클럽을 통하여 궁금했던 질문도 하였고, 앞으로 나아갈 길과 동기를 얻을 수 있었다. 다음 기수에도 신청하고 싶다

[출처]

• 인프런 워밍업 클럽 : https://inf.run/Y4cf2

• 강의 : https://www.inflearn.com/course/readable-code-%EC%9D%BD%EA%B8%B0%EC%A2%8B%EC%9D%80%EC%BD%94%EB%93%9C-%EC%9E%91%EC%84%B1%EC%82%AC%EA%B3%A0%EB%B2%95/dashboard