5/9

단위 테스트

단위 테스트란?

작은 코드 조각(단위)을 검증
빠르게 수행 가능
격리된 방식으로 처리

통합과 고립

협력 객체를 실제 객체로 사용하는지 mock 객체로 사용하는지에 따라 테스트 구현이 달라진다.

Test Double

실제 객체 대신 사용되는 모든 종류의 객체에 대한 일반 용어
즉, 실제를 가짜 버전으로 대체한다는 의미

Stub

테스트 중에 만들어진 호출에 미리 준비된 답변을 제공하며 일반적으로 테스트를 위해 프로그래밍된 것 외에는 전혀 응답하지 않는다.

mock() 을 사용하면 stub 객체를 만들 수 있다.

@Mock 을 사용해도 stub 객체를 주입받을 수 있다. @MockBean 는 스프링 컨테이너에 올라가는 객체를 stub 객체로 만들 때 사용한다.

Fake

실제 객체가 있고, 실제 객체와 똑같은 행위를 하는 비슷한 Fake 객체를 만드는 것.

협력 객체를 실제 객체로? 가짜 객체로?

실제 객체를 사용하면 협력 객체의 행위를 협력 객체 스스로가 정의한다. 가짜 객체를 사용하면 협력 객체의 행위를 테스트가 정의한다.

실제 객체를 사용하면 협력 객체의 상세 구현에 대해 알 필요가 없지만 협력 객체의 정상 동작 여부에 영향을 받는다.

테스트 코드를 작성할 때

가짜 객체를 활용하면 실제 객체를 사용할 때보다 좀 더 편하게 테스트를 작성할 수 있다.

그러나 상세 구현에 의존하는 테스트가 될 수 있다.

Mockist의 단위 테스트

테스트 대상을 협력 객체로부터 격리하기 위해 테스트 대상이 의존하는 모든 것을 가짜 객체로 대체한다.

따라서 Line과 Station 모두 잘 동작하는지 검증한다는 것은 단위와 단위의 통합이 잘 동작하는지를 검증하는 것이다!

Outside In

Mockist TDD (London style)

상위 레벨 테스트부터 시작한다. 테스트 더블을 활용해서 테스트 대상이 의존하는 협력 객체의 예상 결과를 정의하고, 다음 사이클로 테스트 더블로 미리 정의한 협력 객체를 테스트 대상으로 한다.

단점

Inside Out

Classic TDD(Chicago style)

실제 객체를 다뤄야 하기 때문에 도메인 모델을 시작. 의존하는 협력 객체가 실제 존재해야 테스트를 작성할 수 있다. 공유하는 객체(외부 리소스)를 사용할 때는 가짜 객체를 사용하기도 한다.

단점 도메인 설계가 충분히 이루어진 다음 진행 가능하다. TDD 사이클을 이어나가기가 상대적으로 어렵다.

각 방법의 장단점이 명확하다. 둘 중 하나를 선택해야 하는 문제가 아니다. 컨트롤러를 먼저 만들 것인지, 도메인 모델을 먼저 만들 것인지는 정답이 없다.

아는 것에서 모르는 것으로

사실은 상향식, 하향식 둘 다 TDD의 프로세스를 효과적으로 설명해줄 수 없다. 만약 어떤 방향성을 가질 필요가 있다면 아는 것에서 모르는 것으로 가는 방향이 유용할 것이다. 우리가 어느 정도의 지식과 경험을 가지고 시작한다는 점, 개발하는 중에 새로운 것을 배우게 될 것임을 예상한다는 점 등을 암시한다.

5/10

워크숍 Day 1

각자 쓰고 싶은 주제에 대한 이야기 나누기
1. 어떤 경험을 글에 담아내고 싶은지 이야기하기
2. 왜 이 주제를 선택했는지, 어떤 경험에서 비롯된 소재인지, 어떤 형식의 글을 쓰고 싶은지, 예상 독자는 누구인지 등등
저자의 이야기를 듣고 다른 사람들은 그 이야기를 4-5줄로 간단히 요약
독자들이 요약해 준 글에서 본인 이야기의 핵심이라고 생각하는 부분을 뽑아 한 문장으로 공유

글의 핵심 씨앗 만들기 (소재 탐색하기)

각자 쓰고 싶은 주제에 대한 이야기를 나눌 때, 저자가 아닌 다른 크루들의 역할이 매우 중요하다. 저자가 주제에 대해 소개할 때, 소재(쓸 거리)를 풍부하게 찾아낼 수 있도록 경험을 끌어내주자.

그 주제에 대해 가장 좋았던 경험? 그 주제와 관련해 힘들고 후회되는 경험? 재밌었던 일화 등등

목차 만들기

각 그룹에서 글의 목차를 함께 만든다. 글에서 가장 핵심이 되는 부분을 위에 적고, 핵심을 더 잘 드러내기 위한 내용을 목차로 함께 추가해야 한다. 핵심과 멀어지는 부분을 추가하는 것을 지양한다.

레벨2 4주차

5/9