Delphi тестирование при помощи подмен на Mock

[r3code]

Mock - это техника тестирования заменяет вызов к реальному объекту на вызов к подменному объекту, который возвращает нужные данные сразу. Это особенно актуально, когда нужно абстрагироваться от внешнего окружения. Т.е. вместо обращения к реальной БД при вызове сразу получаем заполненный DataSet.

Примеры использования

1. Какую библиотеку Mock выбрать?

Comments

[r3code]

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

[ne_chervonec]

Интерфейсы конечно хорошо. Но по мере увеличения количества тестов становится довольно сложно их сопровождать.
Моки сопровождать не надо + они очень лёгковесные, что незаменимо при юнит-тестировании. Ведь юнит-тесты должны компилироваться и исполняться практически мгновенно :)

Самая живая из библиотек по-моему Delphi Mocks.

Ещё интересная штука - плагин TestInsight. Он хоть грубо, но имитирует работу MSTest в VisualStudio. Он позволяет автоматом запускать юнит-тесты когда работаешь в редакторе Delphi и сразу показывает результаты прогона.

[r3code]

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

[ne_chervonec]

Количество тестов зависит от сложности проекта.
У меня в текущем проекте есть класс, на покрытие которого потребовалось как раз 50 тестов.
Интерфейсы хорошо использовать для простых стабов. Но тогда сложно проверять взаимодействие объектов между собой. Чем сложнее логика работы тестируемого класса, чем больше у него внешних зависимостей, тем более изощрённые фейковые объекты придётся писать для тестов.

Простой пример - чтение данных из потока.
В зависимости от формата данных в потоке может вызываться та или иная последовательность методов интерфейса-читателя. Соответственно, мок должен запоминать эту последовательность.
Если код тестируемого класса/интерфейса меняется, то придётся переписывать и мок-класс. Если код меняется часто, то затраты на поддержку тестов станут слишком большими.
Рано или поздно придётся написать свою библиотеку моков, чтобы абстрагироваться от конкретных "интерфейсов", используемых в тестах. Благо в последних версиях Delphi это относительно несложно сделать.