Здравствуйте, zelenprog, Вы писали:

Z>В данном случае мне надо протестировать полную реализацию get-запроса, которая выполняет много разных действий и в том числе работает с хранилищем.
Z>При работе с хранилищем (например при чтении из хранилища данных) используется вот такой код:
Z>

Z>async fn read(mut db: Connection<LogsDB>, id: i64) {
Z>    let res = sqlx::query("SELECT content FROM logs WHERE id = ?").bind(id)
Z>        .fetch_one(&mut **db).await;
Z>    ....
Z>

Z>db — это параметр типа "Connection<LogsDB>", который передается в эту функцию.
Z>Вот хорошо бы этот код тоже протестировать.

Z>Конечно, можно было бы вместо параметра "db" типа "Connection<LogsDB>" сделать интерфейс (трейт) с одной функцией "get_connection()" и передавать в функцию этот трейт вместо "Connection<LogsDB>".
Z>Но тогда я не протестирую "рабочий" код.

Я точно не имею огромного опыта в rust, и не знаю нюансов использования какого там фреймворка, но что значит "рабочий код"? Точно не внутри библиотечный — же. Мы не проверяем как именно работает условный fetch, нам надо убедиться, что "рабочий код" создал корректный запрос и адекватно реагирует на описанные в документации этого fetch ошибки.

Тогда мы мокаем эту самую библиотечную сущность и описывем в них тестовое поведение для "рабочего кода". Используя старые добрые разные реализации интерфейсов, которые и дёргаем в нашем "рабочем коде".