Тестирование на основе наблюдений - более или менее термин Agitar для использования их продукта. Я оценил продукт Agitar несколько лет назад. Он не заменяет обычное модульное тестирование, но работает вместе с ним. Хотя есть процесс его использования, как и во всем, я бы не стал рассматривать его как процесс на уровне TDD, CI или CD - это похоже на использование инструмента статического анализа, как на тестирование. Тем не менее, это очень мощный и интересный.
Его основной функциональностью является обнаружение инвариантов, которое Agitar называет агитацией. Он находит все методы в вашем коде и выполняет каждый с автоматически определенным набором значений параметров. Он изощрен в том, как он выбирает значения параметров: он делает относительно очевидные вещи, такие как использование MIN_VALUE, -1, 0, 1 и MAX_VALUE для целых чисел, но он также может наблюдать за выполнением существующего тестового кода и собирать интересные значения для использования при перемешивании. Он имеет явную поддержку объектов с внешними зависимостями, таких как JDBC Connections.
После запуска всех методов класса с выбранными значениями параметров Agitar производит наблюдения (возможные варианты) относительно значений параметров, возвращаемых значений метода и значений полей. Он представляет их пользователю, который может либо преобразовать их в инварианты, которые будут проверены в будущих прогонах агитации, либо изменить код, чтобы наблюдение стало невозможным. Например, Agitar может заметить, что вызов метода с одним параметром, равным нулю, приводит к выбрасыванию метода NullPointerException. Изменение кода для обработки нулевого значения устранит это наблюдение в будущих прогонах.
Agitar может генерировать тесты JUnit на основе своих наблюдений. Я не знаю каких-либо преимуществ по сравнению с поддержанием инвариантов в инструменте Agitar.
Я не купил продукт Agitar, но я все еще испытываю большое уважение к тому, что видел, и хотел бы еще раз рассмотреть его в подходящей среде (Java, сильная потребность бизнеса в пуленепробиваемом коде). Он обнаружил ошибки в коде, который я разработал с помощью TDD и который охватывал почти 100% линий и ветвей. Более того, наблюдение за его работой улучшило мои представления о модульных тестах!
Что касается подводных камней: он специфичен для Java, является частным и дорогим. Кроме того, поскольку это настолько тщательный инструмент, а его наблюдения связаны с деталями реализации, потребуется много усилий, чтобы сохранить представление Agitar о программе, которая активно разрабатывается (больше, чем поддержка набора приемки / интеграции / модульного тестирования). .
Это лучшее быстрое введение в агитацию, которое я нашел: http://www.agitar.com/downloads/demos/agi_demo/agiDemo.html. Здесь есть интересные материалы о предшественниках и связанных с ними системах: http://plse.cs.washington.edu/daikon/pubs/. Кроме того, ScalaCheck кажется реализовать аналогичный, хотя и гораздо более простой процесс.