TDD에 대해서 다시 정리 해본다. - Mock

만약 아직 db 개발이 안 돼있고, 기능을 우선적으로 개발한다고 치면, TDD를 할 때 Mock을 이용하면 좋다.

 

Mock이란 이름과 같이 모조품을 말한다.

 

기능을 우선적으로 개발하게 되면 데이터 값을 넣어야 하는데 이 데이터 값을 모조품인 Mock객체로 넣는다고 생각하면 된다. 

 

---

 실제 객체를 만들기엔 비용과 시간이 많이 들거나 의존성이 길게 걸쳐져 있어 제대로 구현하기 어려울 경우, 이런 가짜 객체를 만들어 사용한다

---

책에서 Mock의 정의가 이렇게 써져있다. 

 

(이 책.. 왜 절판된건지 궁금하다 내용면으로 너무 괜찮은 책인데. 좀 더 추가 생산했으면 안 됐나 ㅠ..)

 

암튼 Mock은 

 

1. 테스트 작성을 위한 환경 구축이 어려워서

2. 테스트가 특정 경우나 순간에 의존적이라서 

 

이 두가지 경우라고 한다.

 

테스트 작성을 위한 환경 구축이 어려운 이유는 

- 환경 구축을 위한 작업 시간이 많이 필요한 경우에 Mock 객체를 사용한다.

- 경우에 따라서는 특정 모듈을 아직 갖고 있지 않아서 테스트 환경을 구축하지 못할 수도 있다.

- 타 부서와의 협의나 정책이 필요한 경우에도 Mock이 필요하다.

이 세가지로 나뉜다.

 

 그리고 테스트가 특정 경우나 순간에 의존적이라는 이유는

 

예외처리 테스트, 특정 상황을 테스트 시점마다 발생하도록 만드는 것이 어려울 수 없기 때문이다.

이럴 때 Mock을 이용하면 특정 상태를 가상으로 만들 수 있다고 한다.

 

Mock에 대한 기본적인 분류는 TestDouble(대역)로 시작한다.

 

TestDouble에는 DummyObject, Test Stub, Test Spy, Mock Object, Fake Object로 5개로 나뉜다.

 

DummyObject : Dto를 Implements 받아서 가짜 값을 넣음으로써 동작

Test Stub : DummyObject의 확장. 더미 객체를 실제로 동착하게 끔 만듬.

 

책에서는

 

- 단지 인스턴스화될 수 있는 객체 수준이면 더미

- 인스턴스화된 객체가 특정 상태나 모습를 대표하면 스텁

 

DummyObject와 Test Stub의 차이점을 이렇게 나눈다.

 

FakeObject : 페이크객체는 여러 인스턴스를 대표할 수 있으나, 좀 더 복잡한 구현이 들어가 있는 객체를 말한다.

리스트(List)나 맵(Map)을 이용해서 DB 같은 외부 의존 환경을 대체한다. 

 

TestSpy : 특정 객체가 사용됐는지, 그리고 그 객체의 예상된 메소드가 정상적으로 호출됐는지를 확인해야 하는 상황

잘쓰이지는 않는다고 한다.

 

MockObject : 일반적인 테스트 더블은 상태(state)를 기반으로 테스트를 작성한다. Mock 객체는 행위 기반으로 테스트 케이스를 작성한다. 즉. Give When Then을 말하는 것이다.

 

이러한 Mock에 대한 기본적인 분류로 프레임워크가 생겨났는데 

 

이중에서 가장 많이 쓰이는 것은 Mockito이다.

 

그러므로 다음 시간에는 Mockito에 대해서 쓸게용 :)!