Тесты, которые тестируют тесты

Автор: admin от 5-12-2014, 13:16, посмотрело: 352

Или почему в них нет необходимости.

Часто, когда рассказываешь новичкам про автоматическое тестирование, всплывает один и тот же вопрос: «А кто будет проверять сами тесты? Придётся писать тесты для тестов, потом тесты для тестов для тестов…» Все любят рекурсию и ещё больше любят уесть ей собеседника.

Странно, ни разу не попадался вопрос: «Кто тестирует тестировщиков?» — по сути, та же проблема вид сборку.

Но действительно, почему нет необходимости тестировать тесты? (и тестировщиков)

Для остановки мнимой рекурсии следует воспринимать тесты как часть проекта, а не как внешнюю по отношению к нему сущность.

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

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

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


  • В коде функциональности описывается модель устройства, с точки зрения его внутренних механизмов.

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


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

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


На самом деле можно выделить не две, а три модели предметной области:


  • модель в коде функциональности;

  • модель в коде тестов;

  • модель в голове разработчика.


Все три модели строятся на разных принципах, а значит этим можно пользоваться для определения принадлежности ошибки конкретной модели: если две модели говорят А, а третья Б, то логично предположить, что третья не права и именно она содержит ошибку.

Во время работы над статьёй ни один тест не пострадал. Спасибо за внимание.

Источник: Хабрахабр

Категория: Веб-разработка, Game Development

Уважаемый посетитель, Вы зашли на сайт как незарегистрированный пользователь.
Мы рекомендуем Вам зарегистрироваться либо войти на сайт под своим именем.

Добавление комментария

Имя:*
E-Mail:
Комментарий:
Полужирный Наклонный текст Подчеркнутый текст Зачеркнутый текст | Выравнивание по левому краю По центру Выравнивание по правому краю | Вставка смайликов Выбор цвета | Скрытый текст Вставка цитаты Преобразовать выбранный текст из транслитерации в кириллицу Вставка спойлера
Введите два слова, показанных на изображении: *