Должны ли мы всегда проверять ошибки модуля при их исправлении?

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

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

Отсюда мой вопрос: как вы проверяете наличие ошибок, которые сложно воспроизвести? Как избежать создания вещей, которые тестируют реализацию, а также ухудшают рефакторинг и читабельность?

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

Я предпочел бы не писать тесты, а не прерывать работу над ошибками, как правило, больше, чем просто разрабатывать и поддерживать модульный тест.

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

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

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

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

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

Да, ты должен.

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

Это не практика TDD, хотя. В тестах TDD вы управляете своим дизайном, но в вашем случае дизайн уже определен.