Модульные и Интеграционные тесты являются неотъемлемой частью жизни современного разработчика. И если с написанием простейших тестов описанных в различных обучающих статьях проблем обычно не возникает, то ситуация коренным образом меняется, когда нам необходимо написать интеграционные тесты для чего-то более сложного, чем 3 + 2 = 5.

В данной статье я хочу поделиться своим подходом к написанию интеграционных тестов для приложения, использующего Actix Web (API-тестирование).

Писать что-то абстрактное скучно, поэтому давайте напишем интеграционный тест для своего маленького AWS STS.

Note: Статья будет интересна тем, кому по какой-либо причине не подходят стандартные средства Actix Web для написания интеграционных тестов.

Немного об интеграционных тестах

Прежде чем перейти к написанию теста, давайте определимся, как он должен выглядеть и что мы от него хотим. В целом, можно выделить следующие этапы работы интеграционного теста:

Подготовка конфигурации для запуска приложения с тестовыми параметрами.
Запуск web-приложения (часть сервисов может быть выключена или заменена на mock'и).
Проверка работы одного или нескольких сервисных методов (это наш тест).
Остановка приложения.

К сожалению, мне не удалось найти альтернативы JUnit с его @BeforeEach/@AfterEach для Rust, поэтому мы будем вынуждены воспользоваться стандартными средствами для тестирования.

Что-то общее для всех тестов

А начнём мы с базовой структуры, которая будет ответственна за хранение информации об

port: u16 - порт, на котором запущено наше приложение.
server_handle: ServerHandle - специальная структура, которая позволяет нам управлять состоянием нашего приложения. (Подробнее про ServerHandle можно почитать здесь.)

use actix_web::dev::ServerHandle;

#[derive(Debug)]
pub struct TestContext {
    pub port: u16,
    pub server_handle: ServerHandle,
}

Также, нам понадобятся две следующие функции:

Для создания тестового контекста и запуска нашего приложения:

impl TestContext {
    /// Create TestContext and start web-application with random available port.
    pub async fn new() -> TestContext {
        let port = get_available_port().expect("Failed to bind available port for Test Server");

        let server = crate::create_http_server(|| crate::config::AppConfig::with_params("file::memory:?cache=shared", port.clone()))
            .await
            .expect("Failed to start Test Server");

        let server_handle = server.handle();
        actix_rt::spawn(server);
        TestContext { port, server_handle }
    }
    ...
}

Для остановки приложения:

impl TestContext {
    ...

    /// Stop web-application
    pub async fn stop_server(&mut self) {
        self.server_handle.stop(false).await;
    }
}

Функция get_available_port() позволяет получить свободный port для запуска приложения. Таким образом мы можем запустить несколько изолированных версий приложения для каждого теста (если это необходимо).

Время теста

Пришло время познакомиться с самим интеграционным тестом:

use aws_credential_types::provider::SharedCredentialsProvider;
use aws_sdk_sts::config::Region;

use super::*;

#[actix_rt::test]
async fn assume_role() {
    // Creating test context and starting web-application on random available port
    let mut ctx = TestContext::new().await;
    let port = ctx.port;
   
    // Given
    let config = aws_config::SdkConfig::builder()
        .region(Some(Region::new("eu-local-1")))
        // since our application is executed locally, 
        //        we can use 'localhost' to access it
        .endpoint_url(format!("http://localhost:{}/", port))
        .credentials_provider(SharedCredentialsProvider::new(credentials_provider()))
        .build();
    let client = aws_sdk_sts::Client::new(&config);

    let test_role_session_name = "s3_access_example";

    // When
    let response = client
        .assume_role()
        .role_arn("arn:aws:sts::000000000000:role/rd_role")
        .role_session_name(test_role_session_name)
        .send()
        .await
        .expect("Failed to assume role");

    // Then
    let assumed_role_id = response
        .assumed_role_user()
        .expect("AssumedRoleUser property should be available in the response")
        .assumed_role_id()
        .expect("AssumedRoleId property should be available in the response");

    let parts = assumed_role_id.split(":");

    assert_eq!(test_role_session_name, parts.enumerate().last().unwrap().1);

    // Stopping web-application
    ctx.stop_server().await;
}

Обратите внимание, что код выше использует стандартный клиент для доступа к функциям AWS STS: aws_sdk_sts.

Давайте пройдёмся по ключевым местам теста:

Макрос#[actix_rt::test] используется для того, чтобы указать, что данная асинхронная функция будет выполнена в рамках Actix system.

#[actix_rt::test]
async fn assume_role() {

Важно: данный макрос используется вместо #[actix_web::test].

Инициализируем наш тестовый контекст и одновременно запускаем Actix Web приложение. Логика по запуску приложения была помещена в конструктор TestContext для экономии места. Также это позволяет гарантировать, что port, указанный в TestContext, будет "захвачен" соответствующим объектом приложения.

let mut ctx = TestContext::new().await;
let port = ctx.port;

Непосредственно наш тест описанный с помощью Given/When/Then.

let mut ctx = TestContext::new().await;
let port = ctx.port;

Последний шаг - завершаем приложение после выполнения теста.

ctx.stop_server().await;

Не всё так просто

Как вы могли видеть, тест получился достаточно простым, но в тоже время есть ещё одно изменение, которое необходимо сделать. И касается оно точки входа в нашем приложении:

#[tokio::main]
async fn main() -> std::io::Result<()> {
    dotenv().ok();

    logger::init_with_level(LevelFilter::Debug);
    create_http_server(|| AppConfig::init())
        .await
        .expect("Failed to Run HTTP server...")
        .await
}

Те, кто знаком с Actix Web, сразу обратят внимание, что используется Tokio runtime (макрос #[tokio::main]) вместо #[actix_web::main]. Это связано с тем, что мы хотим самостоятельно управлять состоянием Actix Web HTTP сервера.

Ниже вы можете увидеть укороченную версию функции, отвечающей за создание HTTP-сервера:

async fn create_http_server(app_config_factory: impl Fn() -> AppConfig) -> std::io::Result<Server> {
    let app_config = app_config_factory();
    // connect to db
    ...

    let app_data = web::Data::new(sts_db);

    // start HTTP server
    log::info!("Starting Local Rust Cloud STS on port {}", app_config.service_port);
    let server = HttpServer::new(move || {
        App::new()
            .app_data(app_data.clone())
            .service(handle_service_request)
            .wrap(actix_web::middleware::Logger::default())
    })
    .bind(("0.0.0.0", app_config.service_port))?
    .run();
    return Result::Ok(server);
}

Эта же функция используется в нашем TestContext для запуска HTTP-сервера:

let server = crate::create_http_server(|| crate::config::AppConfig::with_params("file::memory:?cache=shared", port.clone()))
    .await
    .expect("Failed to start Test Server");

let server_handle = server.handle();
actix_rt::spawn(server);

Где actix_rt - это основанный на библиотеке tokio однопоточный асинхронный runtime для экосистемы Actix.

Плюсы и минусы подхода

Главный и несомненный плюс данного подхода - мы получили возможность запустить приложение целиком (или частично) и протестировать его работоспособность в рамках интеграционных тестов.

К минусам можно отнести усложнение конфигурации по сравнению со стандартной инициализацией Actix Web приложения.

Запускаем тест

Напоследок запустим тест и проверим, что он проходит:

damal@lmde5:~/Documents/projects/local-rust-cloud/local_rust_cloud_sts_rs$ cargo test 
Finished test [unoptimized + debuginfo] target(s) in 0.15s 

Running unittests src/main.rs (/home/damal/Documents/projects/local-rust-cloud/target/debug/deps/local_rust_cloud_sts_rs-adc0d1a1499b843e)

running 1 test test tests::assume_role::assume_role ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.04s

Спасибо, что дочитали до конца :)

Исходный код проекта доступен на GitHub.

Пишем интеграционные тесты для Actix Web