Нечего на автотест пенять…

Привет.

Несколько слов о потенциально слабых местах автотеста. Список, представленный ниже – субъективный, может определяться разными факторами (набитые шишки, специфика продукта, используемые инструменты, приоритеты, воззрения, требования, устоявшиеся практики и модные тенденции, наличие человеческих и временнЫх ресурсов и прочее, и прочее, и прочее). Соответственно, представленный список – это сборная солянка из непрограммистских, околопрограммистских и программистских признаков. Представлен в порядке от наиболее терпимого изъяна к наиболее критичному. Расположение в списке субъективно и может меняться. Это всего лишь срез, который завтра может быть другим.

false negative test (в продукте бага нет, но тест красный – обычно это выявляется быстро)
тест не эффективен по критерию “количество затраченных усилий / полученный результат”
несколько тестов в рамках одного теста (если тест красный, не сразу ясно из-за чего именно)
неавтономный тест (зависит от других тестов)
по коду и комментариям непонятно назначение теста
логика и данные в одном флаконе (не всегда плохо, но когда плохо, это сильно усложняет модификацию теста)
неоптимальный код с точки зрения возможностей языка программирования
в тесте нет параметризации (хардкод входных параметров и ожидаемого результата внутри теста)
если тест красный, сложно понять причину фэйла
тест выполняется долго (явные ожидания каких-либо событий, большой объем вычислений и т.п.)
тест может зависнуть (препятствует выполнению следующих тестов)
хрупкий тест (нестабильный — может быть красным или зеленым без изменения в коде, среде, продукте)
тест не запускается регулярно (забыли о тесте — думаем, что запускаем, но по факту нет)
false positive test(в продукте есть баг, но тест, написаный на этот use case, говорит, что все хорошо)

Пользуясь случаем: мы в Veeam будем рады новым боевым товарищам. Подробности тут.

Здоровья, счастья и благополучия в Новом Году!

Источник