Как мои автоматические проверки врали мне зеленым цветом

[krvfjss]

Да, я иногда вставляю в программы глюкогенератор при сборке с определенными ключами. Например, деление на ноль. И специальные тесты проверяют, что исключение обрабатывается корректно. Или выделение буфера на триллион байт. Тест проверяет, что программа реагирует на нехватку памяти корректно.

Мы все привыкли чисто формально писать типовые обработчики try catch, которые никогда не срабатывают при нормальных условиях. И потому не тестируются. И я так делал. Пока однажды не столкнулся с ситуацией, что программа падает, а в логах ничего нет. Оказалось, что в одном из обработчиков ошибок заложена ошибка, при которой лог не пишется. Теперь всегда стараюсь включать в программы код, который имитирует разные сбои. В релиз он не идëт, конечно. Это специальная сборка для тестов на обработку ошибок.

[vdv007]

Доброго времени дня и суток Вам! Спасибо за Вашу историю, что примечательно, чем сильнее становится модель, тем больше хочется доверять ей полностью, но в итоге оказывается, что тесты ничего не проверяющие размножаются также как и ранее.

[krvfjss]

Как говорил один мой товарищ: "Можно написать много контрольного кода в программе, но, большой аппаратный рубильник с красной ручкой выглядит надёжнее". В кибербезопасности есть понятие "Air Gap". Ну а при кодинге моделями критичные проверки должны быть жёстко закодированы руками.

[vdv007]

Отлично сказано - запомню! Про кодирование руками, думаю, что у современного разработчика есть все шансы писать качественный код, но также есть и большой успех по части лени, поэтому - Air Gap будет с нами еще очень долго, это уже очень древний человеческий фактор.

[netch80]

1. В проектах начиная с некоторого уровня серьёзности вводят мутационное тестирование. Если мутация не привела к поломке хотя бы одного теста, который покрывает подвергнутый мутации код, тут что-то не то, тесты не полны, или же тестовая система подломана.

​2) Я делал в своих серьёзных проектах инверсное тестирование. Например, если функция со входом A1 должна дать результат B1, а A2 – B2, то делаю тест, где на входе A2, а ожидается B1. Тест этот должен сломаться (его враппер проверяет это и кладёт в отдельную категорию), если не сломался – наверх выдаётся поломка теста в целом. Обычно этим ловятся проблемы недостаточного понимания спека, но дважды было, что ловились случаи очень тонких ошибок, и ещё один раз таки поломка тестовой инфраструктуры (при определённых комбинациях тестовых проверок и условий, в которых они запускались, негативный результат глушился).

Мне в вашем описании не нравится в первую очередь зацикленность на TDD. Для случаев, когда спек твёрдо ясен, и написание кода – прямолинейная операция, он будет работать в таком виде. На сложных алгоритмических задачах или при изменениях спека уже по результатам написания, он непригоден. Поэтому я его никогда не форсирую, это рекомендация для заметной части случаев, но не более того.

Теперь у меня для них есть общий вывод: когда агент пишет, что все проверил, к этому стоит относиться как к любой проверке и сначала подсунуть ему ошибку.

Заметная часть случаев, пишут рядом, может быть отловлена, если другой агент (другой модели или хотя бы под другим логином) будет специально натравлен искать проблемы в том, что первый создал. Конечно, при этом им придётся платить вдвойне:))

[vdv007]

Доброго времени суток!

Про мутационное тестирование согласен, по сути это тот же принцип: сначала сломать и убедиться, что проверка это заметила. Инверсный тест с отдельной категорией в обертке мне понравился, особенно случай, когда так поймали заглушенный негативный результат. У меня было ровно это: проверка была зеленой, потому что падение где-то по дороге терялось.

Про TDD Вы правы, это не догма. На задачах, где спек меняется по ходу, я его тоже не держу. Важнее, чтобы до слова готово кто-то попробовал это сломать.

Второй агент у меня как раз есть: отдельный проверяющий, который не видит мой чек-лист и судит только результат. Платить и правда приходится дважды, но это дешевле, чем потом разбирать то, что прошло молча.