다행히도 우리는 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)
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가 점점 더 매력있게 느껴진다.
