Коллектив авторов - Rust на примерах

Следующая функция делит два числа.

///

/// # Examples

///

/// ```

/// let result = doccomments::div(10, 2);

/// assert_eq!(result, 5);

/// ```

///

/// # Panics

///

/// Функция паникует, если второй аргумент равен нулю.

///

/// ```rust,should_panic

/// // паникует при делении на 0

/// doccomments::div(10, 0);

/// ```

pub fn div(a: i32, b: i32) -> i32 {

if b == 0 {

panic!("Ошибка деления на 0");

}

a / b

}

Тесты могут быть запущены при помощи cargo test:

$ cargo test

running 0 tests

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

Doc-tests doccomments

running 3 tests

test src/lib.rs - add (line 7) ... ok

test src/lib.rs - div (line 21) ... ok

test src/lib.rs - div (line 31) ... ok

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

Мотивация для документационных тестов

Главная цель документационных тестов - служить примерами предоставляемой функциональности, что является одной из самых важных рекомендаций. Это позволяет использовать примеры из документации в качестве полных фрагментов кода. Но использование ? приведёт к ошибке компиляции, так как функция main возвращает () (unit). На помощь приходит возможность скрыть из документации некоторые строки исходного кода: можно написать fn try_main() -> Result<(), ErrorType>, скрыть её и вызвать её в скрытом main с unwrap. Звучит сложно? Вот пример:

/// Использование скрытой `try_main` в документационных тестах.

///

/// ```

/// # // скрытые строки начинаются с символа `#`, но они всё ещё компилируемы!

/// # fn try_main() -> Result<(), String> { // эта линия оборачивает тело функции, которое отображается в документации

/// let res = try::try_div(10, 2)?;

/// # Ok(()) // возвращается из try_main

/// # }

/// # fn main() { // начало `main` которая выполняет `unwrap()`

/// # try_main().unwrap(); // вызов `try_main` и извлечение результата

/// # // так что в случае ошибки этот тест запаникует

/// # }

pub fn try_div(a: i32, b: i32) -> Result<i32, String> {

if b == 0 {

Err(String::from("Деление на 0"))

} else {

Ok(a / b)

}

}

Смотрите также:

   • RFC505 по стилю документации

   • Рекомендации для API по документационному тестированию

Интеграционное тестирование

Модульные тесты тестируют по одному модулю изолированно: они малы и могут проверить не публичный код. Интеграционные тесты являются внешними для вашего пакета и используют только его открытый интерфейс, таким же образом, как и любой другой код. Их цель в том, чтобы проверить, что многие части вашей библиотеки работают корректно вместе.

Cargo ищет интеграционные тесты в каталоге tests после каталога src.

Файл src/lib.rs:

// Предположим, что наш пакет называется `adder`, для теста он будет внешним кодом.

pub fn add(a: i32, b: i32) -> i32 {

a + b

}

Файл с тестом: tests/integration_test.rs:

// мы тестируем extern crate, как и любой другой код.

extern crate adder;

#[test]

fn test_add() {

assert_eq!(adder::add(3, 2), 5);

}

Запустить тесты можно командой cargo test:

$ cargo test

running 0 tests

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

Running target/debug/deps/integration_test-bcd60824f5fbfe19

running 1 test

test test_add ... ok

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

Doc-tests adder

running 0 tests

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

Каждый файл с исходным кодом в директории tests компилируется в отдельный пакет. Один из путей использовать некоторый общий код между интеграционными тестами - создать модуль с публичными функциями и импортировать их в тестах.

Файл tests/common.rs:

pub fn setup() {

// некоторый код для настройки, создание необходимых файлов/каталогов, запуск серверов.

}

Файл с тестом: tests/integration_test.rs

// мы тестируем extern crate, как и любой другой код.

extern crate adder;

// импорт общего модуля.

mod common;

#[test]

fn test_add() {

// использование общего кода.

common::setup();

assert_eq!(adder::add(3, 2), 5);

}

Модули с общим кодом следуют обычным правилам модулей. Общий модуль можно создать как tests/common/mod.rs.

dev-dependencies

Иногда возникает необходимость иметь зависимости только для тестов (примеры, бенчмарки). Такие зависимости добавляются в Cargo.toml в секцию [dev-dependencies]. Эти зависимости не распространяются как зависимости на другие пакеты, которые зависят от этого пакета.

Одним из таких примеров является пакет расширяющий стандартный макрос assert!. Файл Cargo.toml:

# при стандартной сборке проекта данная зависимость не будет использоваться.

[dev-dependencies]

pretty_assertions = "0.4.0"

Файл src/lib.rs:

// внешний пакет используется только для тестирования

#[cfg(test)]

#[macro_use]

extern crate pretty_assertions;

pub fn add(a: i32, b: i32) -> i32 {

a + b

}

#[cfg(test)]

mod tests {

use super::*;

#[test]

fn test_add() {

assert_eq!(add(2, 3), 5);

}

}

Смотрите также:

Документация Cargo по --">