Единичное тестирование для защиты от производства

Question

Недавно у нас появилась ошибка, в которую мы добавили validates_presence_of к модели, но эта колонка была нулевой для любых записей, созданных до изменения, поэтому был нарушен любой код, который создавал экземпляр модели по старым данным ,

Это похоже на класс ошибок, которые могут быть обнаружены только при проверке на данные о производстве.

Есть ли способ создать модульные тесты, защищающие эти типы проблем?

Answer 1

Говоря о написании автоматических тестов для несчастливых путей или случаев в вашем коде (также называемом отрицательным тестированием), вы в конечном итоге напишите тесты на то, что вы делаете , ожидайте, что произойдет. Возьмите ситуацию validates_presence_of, вы можете написать тест, который проверяет правильность обработки случая, когда столбец был нулевым, потому что теперь вы знаете, что это может произойти. Написание этих тестов до возникновения проблем - сложная часть, потому что вы не знаете, что вам нужно.

Если вы действительно хотите, чтобы предотвратить эти случаи, прежде чем они произойдут, вы могли бы рассмотреть:

1. тестирования на реальные данные: ухватить реалистическую базу данных и запуск функциональных тестов и проверку базы данных в Это. Некоторые вещи, которые следует учитывать при таком подходе:

   • Если база данных, которую вы рассматриваете в качестве справочной информации, имеет данные о клиенте, вы, вероятно, захотите ее анонимно, ради конфиденциальности клиента.
   • Этот подход трудно получить прямо в цикле разработки, так как это дорого стоит для автоматизации настройки и оркестровки. Эта стратегия более подходит для одноразовых усилий, скажем, перед тем, как совершить массовую миграцию или что-то в этом роде.
   • Как я уже говорил ранее, вы по-прежнему писать тесты для вещей, которые вы ожидаете произойдет, но, учитывая, вы увеличиваете свой набор данных, существует высокая вероятность наткнуться на что-то неожиданное

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

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

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

Этот путь может стать еще более прочным при выполнении canary releases, шаблоны anomaly detection применяются в реальном времени поведенческие данные и автоматические откаты запрограммированы в момент, когда все начинает идти не так.