Хрупкие юнит-тесты - это всегда плохо?

Question

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

Answer 1

Юнит-тесты должны быть хрупкими - это должно их легко сломать. Если они не ломаются, то это вовсе не юнит-тесты; это комментарии к коду.

...

или я упускаю суть вопроса?

---

Редактировать: Я должен уточнить свой предыдущий ответ.

Я немного педантично относился к языку. «хрупкий» просто означает «легко ломается». Модульный тест должен легко сломаться. Термин "испытания на хрупкость" должен быть действительно " испытания на хрупкость "; тесты, которые ломаются, когда они не должны. Несмотря на это, намного, намного проще исправить испытание на слишком хрупкое состояние, чем исправить ошибку, которая проскользнула в результате испытания с недостаточной хрупкостью, поэтому продолжайте писать свои хрупкие испытания!

Answer 2

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

Я бы сказал, что вы всегда должны стремиться к наименьшим хрупким тестам, которые вы можете провести, чтобы полностью протестировать вашу функцию / модуль, но если у вас есть 1 или 2, которые являются хрупкими, то в большинстве случаев вам будет хорошо.

Answer 3

IMO, если ваши тесты удостоверяются в том, что код вашего приложения делает то, что он должен делать, и если его изменить, тесты не пройдены, то ваши тесты в порядке. Не могли бы вы определить, что именно вы подразумеваете под "хрупким"?

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

Answer 4

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

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

Определенным «запахом» случайно-хрупкого теста является использование в тесте функции sleep ().

Answer 5

Когда изменение кода, предназначенное для "внутреннего" класса (то есть без изменения API), приводит к сбою теста, есть две возможности:

1. В коде есть новая ошибка, ИЛИ
2. Код правильный, тест требует исправления

Попробуйте уменьшить # 2. Это «хрупкие» испытания.

Answer 6

Да, хрупкость испытаний - это всегда плохо. Но, похоже, это одна из тех вещей, с которыми нам приходится жить, чтобы полностью протестировать наши занятия. Многие классы не могут быть протестированы, как черные ящики, которые принимают некоторые входные данные и возвращают некоторые выходные данные, как вы можете увидеть с помощью Math.cos (). У большинства из них есть побочные эффекты на другие классы или объекты в системе, и вы должны проверить, что классы правильно манипулировали этими объектами. Это означает, что тест должен знать детали реализации тестируемого класса, который создает хрупкие классы.

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

Answer 7

Юнит-тесты по определению хрупкие. Они ломаются при изменении связанного кода (тестируемой системы). Это по замыслу. Вот как модульные тесты дают значение.

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

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

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