다양한 테스트와 Test Double (+Mockist)

Mockito 레퍼런스 https://javadoc.io/doc/org.mockito/mockito-core/latest/org/mockito/Mockito.html

Mockito - mockito-core 3.12.4 javadoc

# Test Double의 종류

Test Double이란 영화 촬영시 위험한 역할을 대신하는 스턴트-더블 배우들처럼 실제 객체를 대신하는 가짜 객체를 테스팅에 사용하는 방법들을 의미한다. 테스트 더블에는 Dummy, Fake, Stub, Spy, Mock이 존재한다.

 

모든 Test Double을 단순히 '테스트 객체'라고 뭉뚱그려 말해도 상관은 없지만, 각각의 용도가 다르고 의사소통을 명확하게 하기 위해서 구분해서 사용하는게 좋다.

 

@ Dummy Object

껍데기만 있고 아무런 동작도 하지않는 객체이다. (파라메타에 전달되는 더미 빈 객체등)

 

@ Fake Object

실제 객체처럼 동작하는 코드를 가지고 있지만, 테스트 용도만 가능하고 실제 서비스에는 적합하지 않은 객체이다.

단순화된 동작을 제공하여 테스트를 용이하게 만든다. H2 같은 인메모리 데이터베이스도 Fake 라고 볼 수있다.

public final class FakeAccountRepository{
    private final Map<Long, Account> data = new ConcurrentHashMap<>();
    private final AtomicLong idGenerator = new AtomicLong();

    public Account findByEmail(String email) {
        return data.values().stream()
            .filter(account -> email.equals(account.getEmail()))
            .findAny()
            .orElse(null);
    }

    public Account save(Account entity) {
        entity.setId(idGenerator.incrementAndGet());
        data.put(entity.getId(), entity);
        return entity;
    }
}

 

@ Stub Object

테스트에서 호출된 요청에 대해 미리 준비해둔 결과를 제공하는 객체이다.

동작여부는 상관없고, 테스트를 위해 미리 준비된 결과물을 응답하는 객체라고 생각하면 된다.

private final class StubAccountRepository{
    public Account save(Account account){
        return new Account("person","123");
    }
    
    public int update(Account account){
        return 1;
    }
}

 

@ Spy Object (Stub + Logging)

Stub 객체의 역할을 가지면서 호출된 내용의 정보를 테스트 로그에 남긴다.

예를 들어 메일링 서비스에서 발송된 메일 개수를 측정하고 싶을 때 사용하면 된다.

 

@ Mock Object

호출에 대한 기대를 미리 명세 specification 해놓고, 해당 내용에 따라 동작하도록 프로그래밍 된 가짜 객체이다.

Fake, Spy처럼 실제 동작을 구현하는게 아니라 Mocking 라이브러리를 이용하여 만든다.

 

그럼 Stub이랑 비슷한게 아닌가? 하는 의문을 가질 수 있다. Stub은 아래와 같이 직접 테스트용 객체를 만든다.

public interface MailService {
    public void send(Message msg);
}

public class MailServiceStub implements MailService {
    private List<Message> messages = new ArrayList<Message>();

    public void send(Message msg) { messages.add(msg); }

    public int numberSent() { return messages.size(); }
}

 

 

Mock은 특정 메서드가 실행되었을 때 반환하는 결과를 모킹(Mocking)하고 테스트를 진행한다.

➡ 특정 동작이 발생했을 때 바이트코드 조작으로 가로채서 내가 원하는 결과를 반환하도록 바꾼다.

➡ Mocking은 메소드 호출뿐만아니라 객체생성, 예외발생, 메서드 호출여부(verify)도 처리할 수 있다.

즉 Stub은 [처리된 결과, 상태]를 검증하는 용도이고 Mock은 [행위, 메서드 자체]를 검증하는 용도이다. 

 

---

# 테스트의 종류

흔히들 테스트를 작성할 때 단위테스트, 통합, 기능, 승인 테스트라는 용어를 쓴다. 이에 대해 알아보자.

 

@ 학습 테스트 (learning Test)

이는 프로젝트 테스트와는 연관이 없다. 말 그대로 어떻게 동작하는지 개발자의 학습, 이해를 돕기위한 테스트.

python 콘솔창을 열어  if(3) print("A") 가 동작하는지 돌려보는 것도 일종의 학습테스트라고 볼 수 있다.

 

프로젝트 내부에 학습테스트를 작성해주면 다른 개발자들이 돌려보고 해당 코드가 어떻게 동작하는지 참고할 수 있다.

물론 필요하지 않을 때는 테스트가 동작하지 않도록 빌드시 발생하는 자동 테스트에서 제외시켜는 것을 잊지말자. 

 

@ 단위 테스트 (Unit Test)

[테스트가 가능한 가장 작은 단위의 코드]를 테스트하는 기법이다. 한글로 번역하니 의미가 조금 어색하긴 하다.

• 단위테스트는 [테스트를 하는 코드]를 제외하고는 다른곳과 완벽하게 독립적이어야한다.
  ➡ 회원가입 비즈니스 로직을 테스트한다면 회원이 잘 가입되는지 테스트하는거지, 웹 서버의 정상동작 여부나 다른 곳에서 발생한 에러까지 잡을 필요는 없다.
  
• 그래서 단위테스트에서는 Test-Double을 사용해 다른 곳과 연결을 끊어 독립적으로 만든다.
  ➡ 테스트의 대상 범위가 작기에 전체 시스템중 어디에 문제가 파악하기 쉽다는 장점이 생긴다.

// 여기에서는 Mock을 사용하여 단위테스트를 진행하였다.
public void UpdateItem_changes_title(){
    
    // Arrange (Given) - 테스트를 위해 미리 준비되어야 하는 것들
    IRepository repository = Mock.Of<IRepository>();
    var sut = new BusinessLayer(repository);
    int id = new Random().Next();
    string title = Guid.NewGuid().ToString();
 
    // Act (When) - 테스트를 하고 싶은 곳, 동작이 발생하는 곳
    sut.UpdateItem(id, title);
 
    // Assert (Then) - 원하는 테스트 결과
    Mock.Get(repository)
        .Verify(x => x.Update(id, title), Times.Once());
}

 

 

@통합 테스트 (Integration Test)

쉽게말하면 다른 곳과 독립적이지 않은 그냥 테스트. 새 코드를 작성할 때 [단위 테스트 케이스]를 작성하고, 이미 작성된 둘 이상의 시스템이 조립되어 잘 동작하는지 확인할 때 [통합 테스트 케이스]를 작성한다. 

 

여러가지 객체들을 실제로 같이 돌려봤을 때 문제없는지 테스트하는 목적도 있지만, 외부 라이브러리등을 함께 사용했을 때 발생하는 문제도 여기에서 검증한다.

* 다만 테스트를 작성할 때 단위테스트와 통합테스트를 나눌 필요가 없는데 억지로 구분해서 만드는건 좋지 못한 방법이다. 테스팅의 본질은 요구사항을 충족하는지, 이게 신뢰할 수 있는 설계인지, 잠재적인 버그는 없는지 확인하는 것이기 때문이다. 

 

@인수, 승인 테스트(Accpetance Test)

이것도 한글로 번역한 의미가 상당히 어색하다. 영어로는 Acceptance Test

말 그대로 소프트웨어가 기획대로 잘 동작하는지 테스트이다. 일종의 블랙박스 테스트라고 볼 수 있다.

➡ 단위, 통합테스트에서 검출하기 어려운 시스템문제, 실제 서비스 호스팅 환경등을 함께 테스트하는 방법이다.

mocking 없이 실제 전체 서비스를 동작시켰을 때 잘 돌아가는지 확인하는 테스트

단위, 통합테스트만 진행해서는 전체서비스가 잘 동작하는지 확인하기 어렵다. 주기적으로 인수테스트를 해줘야한다.

 

다만 단위테스트, 통합테스트와 다르게 실제로 모든 서비스가 동작하는거라 테스트 시간이 매우 길고 어떤 코드에서 문제가 발생했는지 찾기가 어렵다.

➡ 그래서 단위,통합테스트는 대부분 자동화하지만 인수 테스트는 필요할 때만 수동으로 직접하기도 한다.

 

 

@ E2E, 기능 테스트(Functional Testing)

인수 테스트(Acceptance Test)와 유사하지만, 필수로 자동화해야하는 테스트이다. 사용자 관점에서 기능들을 하나씩 테스트한다는 의미에서 E2E(End to End) 테스트라고도 부른다.

• 인수 테스트는 내부코드는 상관없고 기획대로 잘 동작하는지만 체크하는 블랙박스 테스트이다.
• 기능 테스트는 화이트 박스이다. 사용자 관점에서 각 기능 단위로 실제 서비스 환경에서 잘 동작하는지 테스트한다.
  ➡ Mock 객체를 사용하지 않고, 실제 배포환경에서 테스트를 실행한다. 말그대로 End-to-End를 다 거치는 테스트

public void UpdateCommand_changes_title_of_item()
{
    // Arrange
    var database = new SqlDatabase(...);
    int id = database.Insert("Hello World");
    string title = Guid.NewGuid().ToString();
 
    // Act
    ExecuteCommand($"Application.exe update {id} {title}");
 
    // Assert
    database
        .Execute("SELECT TITLE FROM ...")
        .Should().Be(title);
 
    // Cleanup
    database.Execute("DELETE ...");
}

 

---

# Mockist와 Classist

현대의 도구들에는 테스트 더블(test-double) 객체들의 기능이 정말 다양하고, 매우 편리하다.

• 도구의 사용은 정말 편하지만 모든 곳에 테스트 객체를 남발하는 Mockist인 사람들이 등장하고 있다.
  ➡ 극단적인 예로, [사칙연산 +]를 사용하지 않고, 테스트 더블을 만들어 사용하는걸 상상해보자.

테스트 대역은 필요할 때 사용하는거지, 무작정 갖다쓴다고 좋은게 아니다.

테스트 대역은 일종의 가정이고, 가정이 늘어날 수록 실제 결과를 예측하기 더 어려워진다.

 

Mockist의 반댓말로 사용되는 Classist의 의미는, 단순히 꼰대처럼

엣끼! Mockito같은 라이브러리를 쓰다니! 자바로만 작성해!

라는게 아니다. 필요할 때만 Test Double을 쓰는 것이 더 좋은 테스트를 작성할 수 있다는 말이다.

 

예를 들어 Presentation (웹 Controller) 계층은 사용자 요청을 Mocking해서 테스트하는게 맞다.

하지만 Domain 계층은 비즈니스 로직을 가진 자바 객체들만 이루어져있으므로, 굳이 Mock을 쓰지않더라도 충분히 테스트 할 수 있다.

 

---

# Mockist와 Classist를 언급하는 이유

이규원님의 그게 통합 테스트라고? 정말?을 읽어보면 왜 이걸 언급했는지 이해할 수 있다.

시나리오1. 조금 극단적인 이야기
- 상품들의 가격 합계를 계산해 JSON으로 출력하는 시스템을 작성한다.
- 이 시스템의 단위테스트를 하는데 JSON 라이브러리를 Mocking하지 않는다. 당연한 이야기이다.

시나리오2. 현실적인 이야기
- 서비스 시스템과 이를 이용하는 클라이언트 시스템을 만든다.
- 간단하게 서비스 인스턴스를 생성할 수 있고, 서비스와 클라이언트는 동일한 프로세스에서 구동되는 개체이다.
- 서비스는 API만 개발 완료되었고, 내부 구현은 아직 개발중이라 동작하지 않는다.
- 그래서 클라이언트 개발자는 단위 테스트하기 위해 서비스 시스템을 Mocking하여 테스트하고 넘어갔다.

- 이후 서비스와 클라이언트는 각각 성공적으로 모든 단위테스트를 완료하였다.
- 그런데 이 두 개를 연결시켰을 때 정상적으로 동작함을 보장할 수 있을까...?
- 결국 Mocking을 사용하지 않은 통합테스트가 추가로 필요하다.

시나리오3. 생각해볼 이야기
- 시나리오2와 동일한 프로그램을 개발하지만, 이번에는 서비스 시스템부터 먼저 개발된다.
- 서비스 시스템이 모든 요구사항을 만족하고, 단위 테스트를 통해 검증을 완료한다.
- 이제 클라이언트 시스템을 만든다.
- 서비스 시스템은 이미 테스트 검증이 완료되었다. 굳이 Mocking할 필요가 없다. 실제 객체로 테스트한다.

- 하지만 나라면 어떨까? 이 경우에도 단순히 편리하다는 이유로 Mocking 하지는 않았을까?
- 그러고나서 단위/통합을 구분하기 테스트를 추가로 작성하지는 않았을까?

테스트 대역을 사용하지 않는다고 통합테스트인게 아니다. 이런 테스팅의 상당수는 테스트 케이스 작성이 힘들어지거나 실행 비용을 증가시키지도 않는다.

 

Mockist가 되어 무작정 모든 테스트를 분리시키고, Test-Double로 대체하는 바보가 되지말자.