по моему опыту, проект, в котором тесты занимают больше пяти минут, это проект, в котором разработчики забивают на тесты :(

Звучит не очень

эээ

пять минут это вообще ни о чём

даже если интеграционные тесты занимают час, это по-моему вполне себе в пределах нормы

На самом деле, да, тесты на транзакциях это круто

даже если интеграционные тесты занимают час, это по-моему вполне себе в пределах нормы

не согласен, но не обладаю сейчас достаточной уверенностью чтобы быть готовым спорить на эту тему

ну, всё зависит от частного случая разумеется

скажем, если интеграционные тесты только на найтли-билде запускаются, то вообще пофигу, сколько они там занимают

хоть час, хоть два, хоть три

но если ты хочешь прям на каждый коммит их запускать, то это уже другая история :)

Ну хз

А если несколько разных баз юзаешь

То транзакции уже не зайдут

скажем, если интеграционные тесты только на найтли-билде запускаются, то вообще пофигу, сколько они там занимают

"интеграционные" в данном случае - термин, который плохо отражает суть тестов, но я его использую, потому что для проведения этих тестов я использую встроенный в cargo механизм, который называется integration tests. Если бы я нашёл, как в diesel делать мок соединения с базой данных, я бы эти же тесты интеграционными не делал

Тут такое

Интеграционные самые высокоуровневые

но если ты хочешь прям на каждый коммит их запускать, то это уже другая история :)

более того, я бы вот эти конкретно тесты хочу запускать в процессе разработки постоянно, не "на ночь", а раз в 2-3 минуты например

Они должны по сути use cases прогонять

Интеграционные самые высокоуровневые

Верно. Поэтому я и не считаю, что тут термин "интеграционные" хорошо подходит

Но так как в cargo уже есть технический термин integration tests и конфиг именно для них, то приходится использовать этот термин там, где он не очень подходит, просто чтобы использовать эту техническую возможность

Они обычно достаточно долго идут

Хотя и их намного меньше остальных

Это уже второй случай со мной, когда моё мнение о том, что такое "интеграционный" тест не совпадает с мнением разработчиков фреймворка :) так что терминология подводит

ну что я могу сказать.. cargo test судя по всему не умеет в хуки

поэтому если нужно побыстрее, то дизелевский вариант норм выглядит

Альтернативный вопрос: тестировал ли кто-нибудь приложения на diesel, и делал ли моки для connection?

(Автор diesel в его чате сказал мне что это невозможно, но мало ли)

Ты не веришь автору дизеля? :)

а есть примеры мокабельных оэрэмов?

безотносительно языка

мне просто интересно, как это чисто принципиально можно сделать

по факту надо запилить мок-бэкэнд же?

А вы не пробовали создать базу, накатить схему и каждый тест в отдельной транзакции запустить?

Работает очень удобно, мокать не надо

ну он так и хочет делать, я так понимаю

Уже предлагали

Но ему чот не нравится

ему не нравится, что cargo test не может засетапить базу, и поэтому каждый тест вынужден делать это заново

вообще можно просто скрипт сделать, который всё сетапит

и вызывать его

типа setup.sh && cargo test

Как в Джанго))

ну а чё бы и нет

вот так сходу не вижу минусов никаких

А в тестах раста есть какой-то testrunner?

Как-то их можно кастомизировать?

на rust возможно как-нибудь написать компилятор? например, вот написал я там brainfuck и как мне сделать так чтобы боло типа rustc build main.rs только для bf например bfc build main.bf

для интереса

если такое вообще возможно

если такое вообще возможно

Такое возможно на любом языке. Даже на js

Rust - язык общего назначения. На нём можно написать практически что угодно

а где можно найти статью или репозиторий какой-нибудь?

просто найти не могу

а где можно найти статью или репозиторий какой-нибудь?

en.wikipedia.org/wiki/Compilers:_Principles,_Techniques,_and_Tools

Там много вариантов по написанию есть

Раст написан на расте, так что 100% можно))

Можно под llvm писать

Это проще

Статей полно

Раст написан на расте, так что 100% можно))

python на python это pypy :)

А раст на расте это rustc

Можно поискать олдовую версию на ocaml

А раст на расте это rustc

ну там не только rust в компиляции участвует

А что ещё?

C++

на котором написан llvm

В самой репе компилятора тоже есть код на плюсах

Но мб legacy

господи зачем там плюсы

на котором написан llvm

из этого таки не следует, что раст написан с использованием плюсов

из этого таки не следует, что раст написан с использованием плюсов

а я сказал только "в компиляции rust не только rust участвует"

с тезисом в таком виде я тоже не соглашусь

я бы сказал, что вообще не имеет значения, на чём написан llvm

особенно если плюсовый код не компилируется в процессе компиляции растокода

(а он не компилируется)

а я сказал только "в компиляции rust не только rust участвует"

Смотря что под компиляцией подразумевать

Llvm тоже компилирует

да, но llvm не компилирует плюсовый код