Комментарии 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 просто не получится.

1) У вас есть чужой код, написанный индусским фрилансером, который не захотел использовать pattern matching-и и записал всё старыми добрыми if-ами. Просто потому, что Rust ему это позволил.

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) значительно лучше, но ещё не заняло доминирующее положение в индустрии.

Ну ведь так и есть. И криворукие, и несовременные — почти прямые потомки Алгола.

> 90% работы QA по таким вопросам прекрасно решается с помощью адекватного компилятора.…

В один прекрасный день команда решает перейти с адекватного компилятора на менее типизированный язык программирования… И вот тут вспоминаются QA.
Задача QA зафиксировать текущее состояние системы и удостовериться, что оно не поменялось при изменениях технологий, языков, систем и т. д.

Да, но разменивать qa на проверку валидации input'ов… Может, лучше экспертизу в продукте качать? Например, что при оформлении документов для юрлиц "возраст" юрлица не особо важен. Или важен, то тогда 400+ не должно вызывать удивления.

Я думаю, что всё имеет значение, когда речь идёт о качестве продуктов.
А чем именно заниматься одной единице QA, инпутом или документами — решают или сами QA или кто-то выше. Приоритеты задач никто не отменял.

Rust evangelism strike force!


Люди еще не готовы к таким технологиям, которые бы заменяли целые отделы.


Но наше дело правое — скоро все будет на расте, это просто вопрос времени.

QA растом (и автоматикой) не заменить, просто они должны заниматься более тонкими вещами, чем ручной проверкой проверки типов.

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 без выкрутасов (т.е. нормализованный).

А, ну с float стерильного типа на входе нет, но есть простейшая проверка is_normal. Или noisy_float, который обещает не давать всякую фигню творить с float'ами молча. Вообще, если вы вес в кг в f32 принимаете, то это уже не очень хорошо. Есть же fixed::FixedU32 для такого.

После того, как завезут const generics. Сейчас нет. Только сравнение в лоб.

Возвращаемся к началу треда: получается Rust тоже криворукий язык программирования.

Почему-бы тогда уж и bool (FALSE/TRUE) ему не попытаться скормить, раз все остальные форматы даёте «попробовать»?
Прям уж все остальные?)) Мне кажется, boolean все же для строки. Хотя, типа распознает ли как 0 / 1?
Как 0/1 или как результат сравнения. Если string не пропускает, то не пройдет ли boolean?
следующая статья будет про проверку корректности ссылок? ;-)

У вас проставлены относительные ссылки. При переходе по ним «из ленты» будет не то поведение, что ожидает пользователь. На приложенном скриншоте показан адрес перехода.

Попробуйте в ленте посмотреть адрес перехода у ссылок «читать далее» и «комментарии». Там установленные абсолютные ссылки.
Специально перешла по ссылкам, они замечательно работают
Они замечательно работают в статье. Но обратите внимание, что я написал про переход по ним «из ленты». А также прикрепил скриншот, где показан некорректный адрес ссылки (он указан в нижнем левом углу).

Чтобы чуть упростить тестирование ссылок из статьи, попробуйте перейти в хаб «Тестирование IT-систем» habr.com/ru/hub/it_testing и спуститься к вашей статье. Перейдите по любой ссылке из тех, что видите на экране (не нажимая «Читать дальше»).
Ну тут уж извините, зачем ставить абсолютные ссылки там, где хватает относительных? Если какая-то ссылка из содержания заинтересовала, заходим в статью и читаем ее. При этом непонятно, почему «плохой» стала почти последняя ссылка, все ссылки на якоря не сработают из ленты
Очень мило в комментариях к статье про тестирование читать «Это не ошибка, это особенность» :-)

Особенно в контексте «вот статья про дюжину проверок введённого возраста».
Почему «девушка» в кавычках? Никто и не отрицает, что я девушка. Или девушек тестировщиков не существует?)
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.