Как написать модульный тестовый фреймворк?

Question

• Как написать фреймворк для юнит-теста?
• Может кто-нибудь предложить хорошее чтение?

Я хочу поработать над базовыми строительными блоками, которые мы используем в качестве программистов, поэтому я подумываю над разработкой инфраструктуры модульных тестов для Java. Я не собираюсь писать фреймворк, который заменит junit; я намерен получить некоторый опыт, выполняя достойный проект.

Answer 1

Есть несколько книг, в которых описывается, как создать структуру модульного тестирования. Одним из них является Разработка через тестирование: на примере (TDD) Кента Бека. Другая книга, на которую вы можете взглянуть, - xUnit Test Patterns: рефакторинг тестового кода от Gerard Meszaros.

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

Если (как показывают ваши комментарии) ваша цель состоит в том, чтобы узнать о факторах, которые входят в создание хорошей структуры модульного тестирования, выполнив это самостоятельно, то главы 18-24 (Часть II: Пример xUnit) книжной выставки TDD как это можно сделать в Python. Адаптация этого к Java, вероятно, многому научит вас по Python, фреймворкам модульного тестирования и, возможно, по Java тоже.

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

Обратите внимание, что сотрудники TDD совершенно уверены, что TDD плохо работает с базами данных. Это неприятно для меня, поскольку моя работа сосредоточена на разработке СУБД; это означает, что я должен адаптировать методы, обычно используемые в литературе, для соответствия реалиям «тестирования на предмет работы СУБД - значит тестирование на СУБД». Я считаю, что основной причиной их беспокойства является то, что настройка базы данных в известное состояние требует времени и, следовательно, замедляет тестирование. Я могу понять это беспокойство - это практическая проблема.

Answer 2

В основном, он состоит из трех частей:

1. подготовка набора тестов
2. выполнение тестов
3. создание отчетов

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

Если вы выберете динамический поиск, вам, вероятно, придется использовать некоторые библиотеки, которые могут анализировать байт-код Java. В противном случае вам придется загрузить все классы в вашем classpath, и это а) требует много времени и б) выполнит все статические инициализаторы загруженных классов и может привести к неожиданным результатам тестов.

Запуск тестов может значительно отличаться в зависимости от особенностей вашей среды. Самый простой способ - просто вызывать методы тестирования внутри блока try / catch, анализировать и сохранять результаты (вам нужно проанализировать 2 ситуации - когда было сгенерировано исключение подтверждения, а когда не сгенерировано).

Создание отчетов - это печать результатов анализа в формате xml / html / wiki или в любом другом формате.

Answer 3

Cook's Tour написан Кентом Беком (я полагаю, он не приписан) и описывает мыслительный процесс, который вошел в написание JUnit. Я бы посоветовал прочитать его и подумать над тем, как выбрать альтернативную линию развития.