Информация об изменениях

Сообщение Re[2]: Создать соединение с БД из тестовой функции (rocket_d от 18.03.2025 7:30

Изменено 18.03.2025 7:30 zelenprog

Re[2]: Создать соединение с БД из тестовой функции (rocket_db_pools)
D>А счего бы вдруг sql запросы отправляются в connection напрямую из get обработчика?

Вообще из get-обработчика вызывается специальная функция-реализация, которая вызывает другие объекты и методы и т.д.
Цепочка вызовов получается достаточно длинная.

Это я для упрощения примера сделал показательный get-обработчик, чтобы показать в чем у меня проблема.
А проблема у меня — получить соединение с БД конкретного типа, который нужен для чтения данных из БД.

D>Разве не должна быть модель, реализующая интрефейс (или трейт), и её мы подменяем в тестах хоть на inmemory, хоть на другое хранилище...


Вообще в принципе — да, согласен.
Но хранилище не надо подменять.

D>... Мы же не хранилище тестируем, так?


В данном случае мне надо протестировать полную реализацию get-запроса, которая выполняет много разных действий и в том числе работает с хранилищем.
При работе с хранилищем (например при чтении из хранилища данных) используется вот такой код:
async fn read(mut db: Connection<LogsDB>, id: i64) {
    let res = sqlx::query("SELECT content FROM logs WHERE id = ?").bind(id)
        .fetch_one(&mut **db).await;
    ....

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

Конечно, можно было бы вместо параметра "db" типа "Connection<LogsDB>" сделать интерфейс (трейт) с одной функцией "get_connection()" и передавать в функцию этот трейт вместо "Connection<LogsDB>".
Но тогда я не протестирую "рабочий" код.
Re[2]: Создать соединение с БД из тестовой функции (rocket_d
D>А счего бы вдруг sql запросы отправляются в connection напрямую из get обработчика?

Вообще в "рабочем" коде из get-обработчика вызывается специальная функция-реализация, которая вызывает другие объекты и методы и т.д.
Цепочка вызовов получается достаточно длинная.

Это я для упрощения примера сделал показательный get-обработчик, чтобы показать в чем у меня проблема.
А проблема у меня — получить соединение с БД конкретного типа, который нужен для чтения данных из БД.

D>Разве не должна быть модель, реализующая интрефейс (или трейт), и её мы подменяем в тестах хоть на inmemory, хоть на другое хранилище...


Вообще в принципе — да, согласен.
Но хранилище не надо подменять.

D>... Мы же не хранилище тестируем, так?


В данном случае мне надо протестировать полную реализацию get-запроса, которая выполняет много разных действий и в том числе работает с хранилищем.
При работе с хранилищем (например при чтении из хранилища данных) используется вот такой код:
async fn read(mut db: Connection<LogsDB>, id: i64) {
    let res = sqlx::query("SELECT content FROM logs WHERE id = ?").bind(id)
        .fetch_one(&mut **db).await;
    ....

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

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