Development/Testing

[Mokito Docs] Part1. Mockito? 그게 뭐지?

bbubbush 2020. 6. 14. 22:43

[학습목표]

  • Mockito의 개념을 이해한다
Mockito is a mocking framework that tastes really good. [각주:1]

Mockito 프레임워크 공식 사이트에 나와있는 설명이다. Mockito는 맛이 좋은 목킹 프레임워크라... 아직은 혼란스럽지만 이번 글을 끝까지 읽고 나면 목히토에서 목디브 한잔이 생각 날 것이다.

 

우선 필요한 개념들을 먼저 설명하겠다.

  1. Test사전적으로는 '시험하다'의 뜻도 있지만, 여기서는 실험, 모의실험의 의미로 테스트라고 사용한다. Test code는 JUnit 프레임워크를 기반하는 모의실험 코드를 뜻한다. 
  2. JUnit: 테스트 코드 작성을 도와주는 JVM 기반 프레임워크이다. 작성한 코드가 의도한 대로 동작하는지 간단한 방법으로 검증할 수 있다.
  3. Mock: 사전적으로는 '놀리다, 조롱하다' 등의 동사와 '엉터리, 흉내 낸 것에 불과한 것' 등의 명사로 나타난다. 여기서는 명사 중 '흉내 낸 것에 불과한 것'이 가장 적절한 번역이다. 본래 표현하고자 하는 클래스나 인터페이스 등을 흉내 낸다. 물론 흉내 내었기 때문에 원본과 동일하게 기능하지는 않는다. Mockito를 이해하기 위해 가장 중요한 개념이다.
  4. Method Stub: 메서드는 무슨 의미인지 아니깐 Stub에 대해 알아보자. 사전적으로는 '그루터기, 꽁초, 몽당연필'이라고 한다. 잘 와 닿는 뜻은 아닌데 '정체성을 잃지 않는 최소한의 상태' 정도로 기억하면 좋다. 그루터기는 더 이상 나무라고 할 수는 없지만, 그렇다고 나무가 아니라고도 할 수 없다. 꽁초나 몽당연필도 비슷하다고 볼 수 있다. 그럼 Method Stub은 '정체성을 잃지 않는 최소한의 상태를 가진 메서드'이다.

메서드 스텁에 대한 설명이 장황했지만, IDE로 Eclipse를 사용한다면 우리는 이미 메서드 스텁의 개념을 사용하고 있었다. 아래 주석을 한번 보자.

 

// TODO Auto-generated method stub

 

눈치가 빠르신 분들은 아시겠지만 이클립스에서 Override 메서드를 할 경우 자동으로 붙여주는 주석이다. 이클립스가 벌써 '할 일 : 메서드 스텁을 자동으로 생성'이라고 여러분에게 전달하고 있다.

 

여기서 조금 더 기억을 더듬어 보면 아래 코드처럼 메서드의 반환 타입에 따라 자동으로 리턴 값을 세팅까지 해주었을 것이다. 

 

public String getName() {
    // TODO Auto-Generated method stub
    return null;
}

 

이것이 스텁이다. 최소한의 기능을 할 수 있도록 구현하는 것, 그 자체이다. 

 

 

반응형

 

너무 길어졌다. 다시 목히토에서 목디브 한 잔 하러 가자. Mokito는 이러한 메서드 스텁을 요청한 클래스에 맞게 자동으로 제공해주는 프레임워크다. 메서드 스텁은 최소한의 동작만 제공하며 유닛 테스트를 하기 위해 다른 객체와의 의존관계를 최소화해준다.

 

class Employee {
    private Department department;
    private boolean isIntern;
    ...
    
    public String getDeptName() {
        if ( isIntern ) throw new NotHasDepartmentException();
        return department.getName();
    }
}

 

Employee.getDeptName()의 기능이 잘 동작하는지 확인하기 위해서는 Department.getName() 메서드가 필요하다. 하지만 생각해보자. 우리가 테스트하고 싶은 것은 Employee 클래스다. Department 클래스가 아니다. 만약 Department.getName() 메서드가 Salary 클래스와 또 의존관계라면? 배보다 배꼽이 더 큰 테스트가 된다.

 

이럴 때 Mokito가 제공하는 mock 객체를 사용하여 Department 클래스를 흉내 내어 getName() 메서드를 스텁으로 제공한다. 이렇게 하면서 개발자가 얻게 되는 이점은 다음과 같다.

 

  • 정말 테스트하고 싶은 클래스만 테스트할 수 있다.
  • 행동과 상태를 분리하여 확인할 수 있다.

아직까지 Mockito가 어떤 맛인지 잘 모를 것이다. 다음 파트에서 실제 mock 객체를 사용하고 검증하는 코드를 통해 진짜 맛이 좋은지 확인해 볼 것이다.