태그 보관물: unittest

Rust unittest를 위한 의존성 격리

다행히도 우리는 unittest의 유용함 잘 알려진 시대에 살고 있기에 더 이상 unittest를 지원하는 프로그래밍 언어를 특별하게 받아들이지 않는다. Rust는 비교적 최신 언어인 만큼 이러한 요구사항들을 적극적으로 받아들여 부가적인 프레임워크의 도움 없이도 언어 자체에서 기본적인 unittest가 잘 지원된다.

다만, Rust는 상속을 지원하지 않기 때문에 Python, Java, C++ 같은 객체지향 언어에서 의존성을 격리 할 때 사용되는 method overriding이나 object patching을 사용할 수는 없다. 일반적인 방법으로 mock injection을 수행할 수 없다면 매번 모든 의존성을 물려 놓고 test를 수행해야만 할까?

다행히도 pytest의 mocker patch 만큼 유연하게는 아니지만, Rust에서도 trait + automock의 조합으로 의존성을 격리해서 unittest를 작성할 수 있다.

Trait

Trait은 객체간의 계약을 정의한다는 점에서 다른 언어의 interface와 닮은 점이 많다. 예를 들어 데이터 베이스에 접근해서 계좌의 잔고를 확인하고 업데이트하는 다음과 같은 간단한 Database trait을 생각해 보자.

pub trait Database {
    // 사용자의 잔고를 반환, 오류가 발생하면 에러 메세지 반환.
    fn get_user_balance(&self, user_id: u64) -> Result<u64, String>;

    // 사용자의 잔고를 amount로 업데이트.
    fn update_user_balance(&mut self, user_id: u64, amount: u64) -> Result<(), String>;
}

우리는 실제 구현이 없는 이 trait을 이용해서 unittest를 위한 mock inject을 수행할 것이다. 즉, 이 trait을 받아들이는 “사용자”를 정의한 다음, 테스트를 위해서는 mock으로 구성된 객체를 넘겨주어서 테스트를 수행하고, 실제로 Database trait을 정의하는 프로덕션 코드는 나중에 정의해서 넘겨주려는 것이다.

WalletService – Database Trait 사용자

이 trait을 받아들이는 “사용자”인 WalletService객체는 이 database trait에 interface를 통해 접근하게 된다. 다음의 코드에서 처럼 출금 기능 구현을 위해 database를 접근한다.

pub struct WalletService<DB: Database> {
    db: DB,
}

impl<DB: Database> WalletService<DB> {
    pub fn new(db: DB) -> Self {
        Self { db }
    }
    // 출금
    pub fn withdraw(&mut self, user_id: u64, amount: u64) -> Result<u64, String> {
        let current_balance = self.db.get_user_balance(user_id)?;
        if current_balance < amount {
            return Err(String::from("잔액이 부족합니다."));
        }
        let new_balance = current_balance - amount;
        self.db.update_user_balance(user_id, new_balance)?;
        Ok(new_balance)
    }
}

fn new(db: DB)에서 정의된 것 처럼, 이 객체는 Database trait을 구현하는 모든 객체를 받을 수 있다. 이제 우리는 Database trait을 구현하는 mock 객체를 이 함수에 넘겨주면 된다.

Mockall Crate – Automock

우리가 WalletService의 database 접근에 대한 동작을 테스트하기 위해 직접 Database trait을 구현하는 mock 객체를 구현할 수도 있겠지만, Mockall crate의 Automock은 이 과정을 편리하게 수행할 수 있도록 도와 준다.

먼저 Mockall crate을 의존성 목록에 추가해 준다.

cargo add mockall

앞서 만들었던 Database trait에 unittest 환경에서만 mock 객체를 생성하도록 #[cfg_attr(test, automock)] 매크로를 선언해준다.

use mockall::automock;


#[cfg_attr(test, automock)]
pub trait Database {
    // 사용자의 잔고를 반환, 오류가 발생하면 에러 메세지 반환.
    fn get_user_balance(&self, user_id: u64) -> Result<u64, String>;

    // 사용자의 잔고를 amount로 업데이트.
    fn update_user_balance(&mut self, user_id: u64, amount: u64) -> Result<(), String>;
}

Mock Object를 이용한 Unittest작성

먼저 출금을 시도 할 때, 예금 조회에서 충분한 금액이 반환되어 성공하는 경우를 테스트 해보자.

#[test]
fn test_withdraw_success() {
    // mockall이 자동 생성한 MockDatabase 구조체 사용
    let mut mock_db = MockDatabase::new();

    // Expectation(기대치) 설정
    // get_user_balance는 인자로 사용자 id인 1을 받아 잔액 1000000을 반환, 1번 호출되어야 함.
    mock_db.expect_get_user_balance()
        .with(mockall::predicate::eq(1))
        .times(1)
        .returning(|_| Ok(1000000));

    // update_user_balance는 인자로 사용자 id '1'과 잔액 '500000'을 받아 성공(())을 반환, 1번 호출되어야 함.
    mock_db.expect_update_user_balance()
        .with(mockall::predicate::eq(1), mockall::predicate::eq(500000))
        .times(1)
        .returning(|_, _| Ok(()));

    // Database trait 사용자인 WalletService에 mock injection
    let mut service = WalletService::new(mock_db);

    // 실행 및 검증
    let result = service.withdraw(1, 500000);
    assert!(result.is_ok());
    assert_eq!(result.unwrap(), 500000);
}

4번째 줄을 보면 MockDatabase::new()로 Database trait의 mock 객체를 생성하는데, 이렇게 생성된 객체는 automock 덕분에 어떤 함수가 몇 번 호출 되었는지 여부와 받은 인자 값 검사 그리고 해당 불려진 함수가 반환할 값을 지정해 주는 함수들이 자동으로 포함된다. 위 코드에서 6번째 줄부터 16번째 줄까지의 내용이 이렇게 자동으로 생성된 mock 객체에서 지원해 주는 함수들을 통해 expectation을 설정하는 주는 부분이다.

  • expect_<함수명>(): trait의 멤버인 함수가 호출되지 않으면 테스트가 실패한다.
  • with(): 해당 함수가 호출될 때 넘겨받은 인자 값을 확인한다.
  • times(): 해당 함수가 호출 된 횟수를 확인한다. 이 경우 함수가 정확히 1번 호출되는 경우가 아니라면 테스트가 실패한다.
  • returning(): 해당 함수가 반환할 값을 지정한다.

예금 부족으로 출금에 실패하는 경우도 작성해 보자.

#[test]
fn test_withdraw_insufficient_funds() {
    let mut mock_db = MockDatabase::new();

    // 잔액이 부족한 상황 연출 (현재 잔액 300000)
    mock_db.expect_get_user_balance()
        .with(mockall::predicate::eq(2))
        .times(1)
        .returning(|_| Ok(300000));

    // 잔액이 부족하므로 update_user_balance는 호출되지 않아야 함 (times(0))
    mock_db.expect_update_user_balance()
        .times(0);

    let mut service = WalletService::new(mock_db);

    let result = service.withdraw(2, 500000);
    assert!(result.is_err());
    assert_eq!(result.unwrap_err(), "잔액이 부족합니다.");
}

전체코드

use mockall::automock;

// 데이터베이스 연동을 담당하는 Trait
#[cfg_attr(test, automock)]
pub trait Database {
    fn get_user_balance(&self, user_id: u64) -> Result<u64, String>;
    fn update_user_balance(&mut self, user_id: u64, amount: u64) -> Result<(), String>;
}

// 데이터베이스를 주입받아 비즈니스 로직을 수행하는 서비스 구조체
pub struct WalletService<DB: Database> {
    db: DB,
}

impl<DB: Database> WalletService<DB> {
    pub fn new(db: DB) -> Self {
        Self { db }
    }

    // 출금 로직 예시
    pub fn withdraw(&mut self, user_id: u64, amount: u64) -> Result<u64, String> {
        let current_balance = self.db.get_user_balance(user_id)?;

        if current_balance < amount {
            return Err(String::from("잔액이 부족합니다."));
        }

        let new_balance = current_balance - amount;
        self.db.update_user_balance(user_id, new_balance)?;

        Ok(new_balance)
    }
}

// Unittest
#[cfg(test)]
mod tests {
    use super::*;

   #[test]
    fn test_withdraw_success() {
        // mockall이 자동 생성한 MockDatabase 구조체 사용
        let mut mock_db = MockDatabase::new();

        // Expectation(기대치) 설정
        // get_user_balance는 인자로 사용자 id인 1을 받아 잔액 1000000을 반환, 1번 호출되어야 함.
        mock_db.expect_get_user_balance()
            .with(mockall::predicate::eq(1))
            .times(1)
            .returning(|_| Ok(1000000));

        // update_user_balance는 인자로 사용자 id '1'과 잔액 '500000'을 받아 성공(())을 반환, 1번 호출되어야 함.
        mock_db.expect_update_user_balance()
            .with(mockall::predicate::eq(1), mockall::predicate::eq(500000))
            .times(1)
            .returning(|_, _| Ok(()));

        // Database trait 사용자인 WalletService에 mock injection
        let mut service = WalletService::new(mock_db);

        // 실행 및 검증
        let result = service.withdraw(1, 500000);
        assert!(result.is_ok());
        assert_eq!(result.unwrap(), 500000);
    }

    #[test]
    fn test_withdraw_insufficient_funds() {
        let mut mock_db = MockDatabase::new();

        // 잔액이 부족한 상황 연출 (현재 잔액 300000)
        mock_db.expect_get_user_balance()
            .with(mockall::predicate::eq(2))
            .times(1)
            .returning(|_| Ok(300000));

        // 잔액이 부족하므로 update_user_balance는 호출되지 않아야 함 (times(0))
        mock_db.expect_update_user_balance()
            .times(0);

        let mut service = WalletService::new(mock_db);

        let result = service.withdraw(2, 500000);
        assert!(result.is_err());
        assert_eq!(result.unwrap_err(), "잔액이 부족합니다.");
    }
}

결론

켄트 벡의 TDD 입문서인 “테스트 주도 개발“을 막 읽고나서 이것을 내 개발 규칙에 도입하려고 노력하던 초기에 gmock에서 제공한다는 함수 호출 횟수를 검사하는 기능을 봤을 때는 “이게 유용하기는 할까?” 하는 의구심을 가졌던 적이 있었다. 그 이후로 이 기능이 mock injection을 할 때 caller의 expectation을 점검하는 무척 유용할 기능이라는 것을 깨닫게 되면서 Java의 unittest에서도 mockito를 선호하게 되었는데, Rust에서도 이러한 기능을 제공하는 crate이 있다는 점이 무척 다행스럽다.

라이브러리 확장 기능이 Rust에서 처음 도입된것도 유일한 것도 아니지만, 현대 프로그래밍 언어가 지향하는 바를 적극적으로 받아들이면서도 고성능을 유지하는 Rust가 점점 더 매력있게 느껴진다.

Rust와 Python unit test의 공존

예전 글에서 vscode의 test explorer에 Rust의 unittest가 보이도록 설정하는 방법을 다룬 적이 있었는데, 여기에 Python test case (여기서는 pytest)도 함께 표시되도록 하려면 .vscode/settings.json을 편집해 주어야 한다.

해당 프로젝트의 경우 가상환경을 source root에 두지 않고 서브 디렉토리인 service/.venv 안에 넣어 두었기 때문에 python.defaultInterpreterPath 값을 이곳으로 직접 설정해 주고 pytest 사용을 위한 설정도 해 두었다.

{
    // Rust unit test
    "rust-analyzer.testExplorer": true,

    // Python virtual environment용 인터프리터 설정
    "python.defaultInterpreterPath": "${workspaceFolder}/service/.venv/bin/python", 
    
    // pytest 사용
    "python.testing.pytestEnabled": true,
    "python.testing.unittestEnabled": false,

    // Python unit test가 있는 디렉토리 경로
    "python.testing.pytestArgs": [
        "service/test"
    ],
    "python-envs.defaultEnvManager": "ms-python.python:venv"
}

그리고 나서 vscode GUI에서도 다시 한번 venv를 설정해 준다. 그냥 프로그램을 재 실행 했으면 이 부분은 건너 뛰어도 되었을 것 같긴 한데, 오류가 계속 뜨길래 수동으로 설정해 주었다.

이렇게 하고 나면 test explorer에 두 언어의 test case들이 모두 표시되는 평화로운 공존상태가 된다.

VScode test explorer에 Rust 테스트 케이스 표시

rust-analyzer extension을 설치했는데도 test explorer에서 rust unit test가 표시되지 않는 경우는 다음을 확인해 보자.

Command palette을 열어서 open settings를 검색한다.

왼쪽 pane에서 Extensions -> rust-analyzer를 선택하고 Test Explorer 항목을 찾아 "Show the Test Explorer view."가 체크되어 있는지 확인한다.

한참을 찾았는데 결국은 이게 disabled된 것이 원인 이었다.

이 항목을 체크하고 나면 vscode를 재실행 하겠다는 창이 뜨고, 재실행 뒤에는 unittest가 text explorer에 표시된다.

참고로 UI를 통해서가 아닌 JSON 파일을 직접 수정하려면 settings.json을 열어서 다음을 추가해 주어도 된다.

{
...
    "rust-analyzer.testExplorer": true,
}