Сообщение 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-запроса, которая выполняет много разных действий и в том числе работает с хранилищем.
При работе с хранилищем (например при чтении из хранилища данных) используется вот такой код:
db — это параметр типа "Connection<LogsDB>", который передается в эту функцию.
Вот хорошо бы этот код тоже протестировать.
Конечно, можно было бы вместо параметра "db" типа "Connection<LogsDB>" сделать интерфейс (трейт) с одной функцией "get_connection()" и передавать в функцию этот трейт вместо "Connection<LogsDB>".
Но тогда я не протестирую "рабочий" код.
Вообще из 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-запроса, которая выполняет много разных действий и в том числе работает с хранилищем.
При работе с хранилищем (например при чтении из хранилища данных) используется вот такой код:
db — это параметр типа "Connection<LogsDB>", который передается в эту функцию.
Вот хорошо бы этот код тоже протестировать.
Конечно, можно было бы вместо параметра "db" типа "Connection<LogsDB>" сделать интерфейс (трейт) с одной функцией "get_connection()" и передавать в функцию этот трейт вместо "Connection<LogsDB>".
Но тогда я не протестирую "рабочий" код.
Вообще в "рабочем" коде из 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>".
Но тогда я не протестирую "рабочий" код.