KK
Самый тупой метод - сделать в самом тесте цикл по итератору. Но тогда ошибка в одной из имплементаций прервёт выполнение теста для следующих имплементаций - это не очень хорошо.
Size: a a a
2020 September 27
Э
Самый тупой метод - сделать в самом тесте цикл по итератору. Но тогда ошибка в одной из имплементаций прервёт выполнение теста для следующих имплементаций - это не очень хорошо.
Ошибки в вектор пихаешь, в конце теста все выводишь.
Э
Если хоть одна есть, то фейлишь тест после вывода.
KK
А если там тупо паника будет?
KK
Тут недавно был опрос про Rust. У меня как-то вылетело из головы и я в пожеланиях забыл написать про улучшения инструментов для тестирования. Уж очень они скромные сейчас в Rust.
Э
А если там тупо паника будет?
Ну, значит паника.
KK
Ну, значит паника.
Придётся городить что-то, что бы ловить панику и "складывать" её тоже в вектор с ошибками 😊
KK
Второй тупой вариант - bash скрипт, который будет менять ENV переменные с указанием какую имплементацию использовать и запускать cargo test 😊
Э
Придётся городить что-то, что бы ловить панику и "складывать" её тоже в вектор с ошибками 😊
Всё уже есть в удобном интерфейсе.
Ct
Второй тупой вариант - bash скрипт, который будет менять ENV переменные с указанием какую имплементацию использовать и запускать cargo test 😊
Макросом нагенерить тестов на каждую имплементацию не вариант?
KK
Макросом нагенерить тестов на каждую имплементацию не вариант?
Может и был бы вариант, если бы не факт что список имплементаций, которые надо тестировать определяется в рантайме, а не в момент компиляции. Некоторые имплементации медленные и требуют доступ к внешним сервисам - запускать с ними тесты надо относительно редко.
Ct
Может и был бы вариант, если бы не факт что список имплементаций, которые надо тестировать определяется в рантайме, а не в момент компиляции. Некоторые имплементации медленные и требуют доступ к внешним сервисам - запускать с ними тесты надо относительно редко.
Положить медленные в отдельный модуль и спрятать под фичу?
KK
Положить медленные в отдельный модуль и спрятать под фичу?
Однако муторно это как-то. Мало того что надо в конфиге прописать параметры подключения в внешнему сервису, так ещё и не забыть запустить тесты с указанием фичи. И для каждой новой имплементации над: добавить фичу и прописать её в макрос
Ct
Однако муторно это как-то. Мало того что надо в конфиге прописать параметры подключения в внешнему сервису, так ещё и не забыть запустить тесты с указанием фичи. И для каждой новой имплементации над: добавить фичу и прописать её в макрос
Зачем ее в макрос прописывать?
KK
Зачем ее в макрос прописывать?
А как иначе макрос сгенерит или не сгенерит тест для нужной имплементации в зависимости от фичи?
Ct
Имеешь условно макрос
gen_tests!(impl_type). Пишешь#[cfg(feature = "slow")]
mod slow_tests {
gen_tests!(slow_impl1);
gen_tests!(slow_impl2);
}
Э
Однако муторно это как-то. Мало того что надо в конфиге прописать параметры подключения в внешнему сервису, так ещё и не забыть запустить тесты с указанием фичи. И для каждой новой имплементации над: добавить фичу и прописать её в макрос
macro_rules test_impls {
($($test_name:ident | $t:ty ;)*) => {
$(
#[test]
fn $test_name() {
<$t as Trait>::trait_fn();
}
)*
};
}
test_impls! {
usize_test | usize;
isize_test | isize;
}Э
Если от фичи зависеть может, то делаешь
($( $(#[cfg($feature:tt)])? $test_name:ident | $t:ty ;)*) => { $( $(#[cfg($feature)])? fn $test_name() { … } )* };Э
Используешь как
test_impls! {
usize_test | usize;
isize_test | isize;
#[cfg(long_long_long)] u128_test | u128;
}