Я думаю, что Майкл довольно хорошо подвел итог: «вещи, которые на самом деле не могут быть формально определены». Оказывается, есть много вещей, которые нельзя указать формально. Юзабилити является одним из примеров (хотя, решив, какое поведение можно использовать, вы можете и должны, конечно, проверить это поведение!). Как это ни парадоксально, многие задачи сокращения чисел не могут быть формально определены: например, прогноз погоды. Цель состоит в том, чтобы предсказать погоду завтрашнего дня, но это не формальная спецификация. Таким образом, вы можете либо проверить, что используемые вами алгоритмы выполняют то, что они должны делать (вычисление средних значений, инвертирование матриц, вещи, которые могут быть формально определены), но тогда ваша программа прогноза погоды может пройти все тесты и все равно ошибаться в 90% случаев. , Или вы можете использовать много исторических данных, чтобы проверить, дает ли алгоритм хорошие прогнозы, но это опасно, потому что он может легко привести к алгоритму, который точен только для исторических данных, которые вы использовали, а не в целом. И это, вероятно, будет означать, что ваши юнит-тесты занимают часы или дни. Что еще хуже, ваш алгоритм может иметь параметры, которые нужно «настроить», например, для используемых измерительных инструментов, и оптимальные параметры могут не совпадать для каждого алгоритма, поэтому модульным тестам потребуется ручное взаимодействие для нахождения хороших параметров. Возможно в теории, но, вероятно, не очень полезно. Я предполагаю, что те же аргументы применимы к OCR, ICR, многим задачам обработки сигналов, распознаванию лиц (и многим другим задачам обработки изображений), типичным инструментам фотошопа, таким как «удаление красных глаз», или алгоритмам ранжирования в поисковых системах (просто назвать несколько примеров ).