이 시리즈는 Rust 공식문서를 통해 공부한 흔적임을 밝힙니다.

지난 시간 우리는 테스트 함수를 작성하는 방법을 알아보았다.
이번 시간에는 cargo test에 적용할 수 있는 옵션과
단위 테스트와 통합 테스트에 대해 알아보도록 하겠다.

테스트 제어

cargo test 명령어는 코드를 테스트 모드로 컴파일하여 테스트 실행파일을 만든다.
기본적으로 이것은 코드 상의 모든 테스트를 병렬적으로 수행하고
코드 상의 출력 결과를 보여주지 않은 채 테스트 결과만을 정리해서 보여준다.
그러나 몇 가지 옵션을 통해 이러한 동작을 변경할 수 있다.

옵션 중 일부는 cargo test 자체에 붙어 테스트를 하는 과정에 영향을 주며
다른 일부는 그것이 생성한 테스트 실행파일에 영향을 준다.
전자는 cargo test 뒤에 바로 붙고 후자는 그 뒤에 --를 구분자로 두고 붙는다.
cargo test에 붙을 수 있는 옵션을 알고 싶다면 cargo test --help를,
테스트 실행파일에 붙을 수 있는 옵션을 알고 싶다면 cargo test -- --help를 사용할 수 있다.

테스트 직렬화

여러 개의 테스트를 실행할 땐 기본적으로 스레드를 이용하여 병렬적으로 수행한다.
병렬적으로 수행하는 것이 직렬적으로 수행하는 것보다 빠르게 실행할 수 있으니 말이다.
그런데 여러 테스트 사이에 공유되는 데이터가 있다면 병렬적인 테스트가 문제가 될 수 있다.
이런 경우에는 --test-threads 옵션을 통해 스레드 수를 조작할 수 있다.
이것은 cargo test로 생성된 테스트 실행파일을 몇 개의 스레드로 실행시킬 것인가 하는 부분으로
테스트 실행파일에 적용되어 다음과 같이 사용할 수 있다.

$ cargo test -- --test-threads=1

출력문을 출력하는 테스트

cargo test는 테스트 성공 시 결과만 출력할 뿐, println!을 통한 출력은 보여주지 않는다.
그리고 오직 실패했을 경우에만 실패 원인 추적에 도움이 되도록 이를 출력해준다.
이는 Cargo가 출력 결과를 가로챘다가 실패했을 경우에만 보여주기 때문이다.
출력 결과를 가로채지 않고 성공한 경우에도 표준 출력을 보여주도록 하기 위해서는
--nocapture 옵션을 사용할 수 있다.
이것은 생성된 테스트 실행파일의 출력값을 어떻게 처리할 것인가 하는 부분으로
테스트 실행파일에 적용되어 다음과 같이 사용할 수 있다.

$ cargo test -- --nocapture

테스트 일부 실행

cargo test 명령어를 사용하면 기본적으로 모든 테스트를 수행한다.
그런데 소스 코드를 부분적으로 수정하고 테스트 할 때마다 모든 테스트를 수행하면
시간이 오래 걸리고 비효율적일 수 있다.
이런 경우에 우리는 cargo test에 원하는 테스트의 이름을 전달하여
해당 테스트만 수행할 수 있다.
cargo test는 전달된 이름이 포함된 이름을 가진 테스트 함수를 실행한다.

여러 개의 테스트 함수가 존재하는 예제를 통해 이를 확인해보자.

peter@hp-laptop:~/rust-practice/chapter11$ cargo new add_some --lib
     Created library `add_some` package
peter@hp-laptop:~/rust-practice/chapter11$ cd add_some/
peter@hp-laptop:~/rust-practice/chapter11/add_some$ vi src/lib.rs

src/lib.rs

pub fn add_two(a: i32) -> i32 {
    a + 2
}

#[cfg(test)]
mod tests {
    use super::*;
  
    #[test]
    fn add_two_and_two() {
        assert_eq!(4, add_two(2));
    }

    #[test]
    fn add_three_and_two() {
        assert_eq!(5, add_two(3));
    }

    #[test]
    fn one_hundred() {
        assert_eq!(102, add_two(100));
    }
}

테스트 이름을 전달하지 않으면 모든 테스트가 실행된다.

peter@hp-laptop:~/rust-practice/chapter11/add_some$ cargo test
   Compiling add_some v0.1.0 (/home/peter/rust-practice/chapter11/add_some)
    Finished test [unoptimized + debuginfo] target(s) in 0.28s
     Running target/debug/deps/add_some-746dbf89f0ac90bf

running 3 tests
test tests::add_three_and_two ... ok
test tests::add_two_and_two ... ok
test tests::one_hundred ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

   Doc-tests add_some

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

peter@hp-laptop:~/rust-practice/chapter11/add_some$ 

add를 전달하면 이를 포함하는 두 녀석만 실행된다.

peter@hp-laptop:~/rust-practice/chapter11/add_some$ cargo test add    Finished test [unoptimized + debuginfo] target(s) in 0.00s
     Running target/debug/deps/add_some-746dbf89f0ac90bf

running 2 tests
test tests::add_two_and_two ... ok
test tests::add_three_and_two ... ok

test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 1 filtered out

peter@hp-laptop:~/rust-practice/chapter11/add_some$ 

그리고 add_two까지 전달하면 이를 포함하는 add_two_and_two만 실행된다.

peter@hp-laptop:~/rust-practice/chapter11/add_some$ cargo test add_two
    Finished test [unoptimized + debuginfo] target(s) in 0.00s
     Running target/debug/deps/add_some-746dbf89f0ac90bf

running 1 test
test tests::add_two_and_two ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 2 filtered out

peter@hp-laptop:~/rust-practice/chapter11/add_some$

만약 매우 오래 걸려서 따로 명시해주지 않는 이상 매번 무시했으면 하는 테스트가 있다면
우리는 제외하고 테스트하도록 설정할 수 있다.
애노테이션을 통해 #[ignore] 특성을 부여하면 된다.
이렇게 하면 cargo test 시에는 실행되지 않다가
cargo test -- --ignored라고 ignore 특성을 가진 녀석도 테스트하도록 명시해야 실행된다.
이로써 꼭 테스트 해야 하는 순간에만 테스트를 하고 평소에는 제외할 수 있다.

테스트 조직화

테스트는 양성 테스트와 음성 테스트로의 구분 외에도
단위 테스트와 통합 테스트로도 나눌 수 있다.
단위 테스트는 패키지 내부의 모듈 단위로 테스트하는 작은 테스트로
비공개 인터페이스까지 테스트할 수 있다.
반면 통합 테스트는 패지지 외부에서 라이브러리를 사용하는 것처럼 테스트하며
공개 인터페이스만을 테스트할 수 있다.

단위 테스트

단위 테스트는 src 디렉토리의 각 파일에 저장되어
그곳에 존재하는 코드를 나머지 코드와 독립적으로 테스트한다.
#[cfg(test)] 특성을 가진 tests 모듈을 만들어 그 안에 테스트 함수를 작성한다.
// 사실 이름이 tests가 아니어도 되긴 하지만 암묵적인 규칙이라고 볼 수 있다.
tests 모듈은 그것이 존재하는 곳에 있는 비공개 자료에 접근할 수 있어
비공개 함수에 대한 테스트도 가능하다.

#[cfg(test)] 특성은 cargo build나 cargo run에서는 컴파일하지 않고
오직 cargo test 시에만 컴파일 및 실행 하도록 하는 특성이다.
cfg()는 "다음 코드는 이런 옵션이 지정되었을 때만 포함할 것"이라고 설정해놓는 것이다.
이로서 테스트가 아닌 빌드에서는 시간과 용량을 절약할 수 있다.

통합 테스트

통합 테스트는 src 밖에 tests 디렉토리를 만들어 그 안에 작성한다.
여기서는 라이브러리 공개 API만을 호출할 수 있어 공개 자료만 접근 가능하다.
각각의 모듈 단위로 테스트를 통과한 것들이 상호작용을 하는 과정에서
어떤 문제가 발생하지 않는지 확인하는 작업이 이루어진다.

우리가 지난 시간에 만들었던 adder 패키지에 통합 테스트를 추가해보자.

peter@hp-laptop:~/rust-practice/chapter11/add_some$ cd ../adder/
peter@hp-laptop:~/rust-practice/chapter11/adder$ mkdir tests
peter@hp-laptop:~/rust-practice/chapter11/adder$ vi tests/integration_test.rs

tests/integration_test.rs

use adder;

#[test]
fn it_adds_two() {
    assert_eq!(4, adder::add_two(2));
}

통합 테스트는 src 디렉토리의 코드와는 별개로 각각의 파일이 서로 다른 크레이트로 작성되어
use 키워드를 통해 그것을 가져다가 사용할 필요가 있다.

tests 디렉토리가 존재할 때 cargo test를 수행하면
단위 테스트 결과 아래에 통합 테스트 결과가 추가로 출력된다.
통합 테스트도 단위 테스트와 마찬가지로 특정 테스트만 실행할 수도 있는데
--test 옵션을 주고 그 뒤에 tests 디렉토리의 파일 이름을 전달하면 해당 테스트만 실행된다.
다음과 같이 작성할 수 있다.

$ cargo test --test integration_test

만약 우리가 tests에서 서브 모듈을 만들어 사용하고자 한다면
그것은 tests 아래에 직접 .rs 파일을 생성하는 게 아니라
내부 디렉토리에 mod.rs 파일을 생성해야 한다.
우리가 생성하고자 하는 서브 모듈이 common이라면
tests/common.rs가 아니라 tests/common/mod.rs로 작성하는 식이다.
이렇게 하면 common을 별개의 테스트 대상으로 테스트 결과에 출력하지 않은 채
tests 내에서 common의 함수를 사용할 수 있다.

바이너리 크레이트의 단위 테스트

그런데 테스트를 할 때 주의할 점은,
main.rs의 코드는 통합 테스트를 진행할 수 없다는 것이다.
바이너리 크레이트의 코드는 외부에 노출할 수 없고 오직 라이브러리 크레이트만 가능하다.
따라서 lib.rs 파일에 코드를 작성하고 main.rs은 그것을 가져다 쓰기만 해야 한다.
테스트가 필요하지 않은 수준의 코드는 main.rs에서 작성할 수 있다.

이 포스트의 내용은 공식문서의 11장 2절 Controlling How Tests Are Run & 11장 3절 Test Organization에 해당합니다.