Comments 35
то разработчик ставит последний «else» на всякий случай — то есть если ВДРУГ вводимое значение не попало ни в одно из условий выше:
Это в криворуких языках программирования такое.
Вот, смотрите на современный язык программирования:
fn check_age (age: u8) -> Result<bool, &'static str> {
match age{
0..=17 => Err("Minor detected"),
19..=85 => Ok(true),
86..=128 => Ok(false),
129..=255 => Err("impossible age")
}
}Ошибка компиляции:
2 | match age{
| ^^^ pattern `18_u8` not coveredОбратите внимание, отрицательных значений (так же как и не значений) быть не может.
90% работы QA по таким вопросам прекрасно решается с помощью адекватного компилятора.… Но нода нам всех милее, так что расширяем qa-отдел, чтобы заменял собой компилятор.
На нормальном языке программирования нарушить соглашение о типах и exhaustive pattern matching просто не получится.
2) Вы сами написали идеальный (по вашему мнению) код со всеми matching-ами, но когда вы его писали, вас кто-то отвлёк, и вы написали
match age{ 0..=18 => Err("..."),
19..=85 => Ok(true),
...И всё, код неверный. Это доказывает, что какой бы ни был супер-безопасный язык, независимые тесты нужны, составленные другим человеком, который может быть не сделает ту же ошибку.
В Rust exhaustive pattern matching. Если вас отвлекли и вы забыли написать один из случаев, код не скомпилируется. Понятно, что можно промахнуться н написать Ok(false) вместо Ok(true) — но мой комментарий был о другом. Логику тестировать надо. Странные вводы (например, "не число", "строку", "ненормализованный флоат" и т.д.) в хороших языках и фреймворках писать не надо, потому что система типов это реализует автоматически.
Есть такое. Старые системные языки ужасны. perl-поколение (perl, python, ruby) хороши для скриптинга, но не для строгости. Java писалась под сильным влиянием C++ со всеми печальными последствиями (NullPointerException и т.д.). Новое поколение языков (rust, elixir, swift — я не уверен, что там exhaustive) значительно лучше, но ещё не заняло доминирующее положение в индустрии.
Ну ведь так и есть. И криворукие, и несовременные — почти прямые потомки Алгола.
В один прекрасный день команда решает перейти с адекватного компилятора на менее типизированный язык программирования… И вот тут вспоминаются QA.
Задача QA зафиксировать текущее состояние системы и удостовериться, что оно не поменялось при изменениях технологий, языков, систем и т. д.
Rust evangelism strike force!
Люди еще не готовы к таким технологиям, которые бы заменяли целые отделы.
Но наше дело правое — скоро все будет на расте, это просто вопрос времени.
Попробуйте то же самое с флоатами провернуть.
float'ы в rust'е настолько офигенны, что вы себе представить не можете. Вы какие хотите поддерживать — нормализованные или все? Ненормализованные: nan, info, положительный и отрицательные нули, ненормализованные нули (у которых мантиса начинается с нескольких нулей). Нормализованные — то, что нормальный человек считает числом.
А передать f32 вместо u8 вам не даст система типов.
Вы мне лапшу на уши не вешайте, а лучше расскажите, что будете делать с illegal_floating_point_literal_pattern.
Откуда оно прилетит? Допустим, это rest, так? Внутри приложения rust — rocket, это фрейморк для рутинга по url'у.
#[derive(FromForm)]
struct User {
name: String,
age: u8,
}
#[get("/check?<user..>")]
fn item(user: Form<User>) {
...
}Если вы передадите на вход что-то, что не похоже на u8 (например, -0.00000000001e-308), то у вас просто не примут запрос — это честный bad request. В коде при этом никакой валидации делать не нужно — функция потребовала u8, значит на вход в age ей передаут u8. А в name будет полностью валидный utf8 без выкрутасов (т.е. нормализованный).
При чём тут age? Вам нужно принять f32 вес в килограммах.
Попробуйте в ленте посмотреть адрес перехода у ссылок «читать далее» и «комментарии». Там установленные абсолютные ссылки.
Чтобы чуть упростить тестирование ссылок из статьи, попробуйте перейти в хаб «Тестирование IT-систем» habr.com/ru/hub/it_testing и спуститься к вашей статье. Перейдите по любой ссылке из тех, что видите на экране (не нажимая «Читать дальше»).
Чек-лист для тестирования числового поля