Как избежать дублирования модульных тестов при тестировании взаимодействий на композитах?

Question

Представьте себе систему фильтров (может быть, аудио-фильтры или фильтры текстового потока).

В базовом классе Filter есть метод do_filter(), который принимает некоторые входные данные, изменяет их (возможно) и возвращает их в качестве выходных данных.

Существует несколько подклассов, построенных с использованием TDD, и у каждого есть набор тестов, которые проверяют их изолированно.

Наряду с этим создается составной класс несвязанного типа Widget, который имеет два члена различных типов Filter (a и b), которые имеют дело с совершенно разными входными данными, то есть с определенным входным будет изменен фильтром a, пропущен через немодифицированный фильтром b и наоборот. Его process_data() метод вызывает каждый элемент фильтра do_filter().

При разработке составного класса появляются тесты, которые проверяют предположение, что оба фильтра Widget не обрабатывают одни и те же данные.

Проблема в том, что такого рода тесты выглядят идентично тесту отдельного фильтра. Хотя могут быть и другие тесты, которые проверяют входные данные, которые должны быть изменены обоими фильтрами, многие из тестов могут быть почти скопированы и вставлены из каждого теста фильтра, с небольшими изменениями, необходимыми для их тестирования. с Widget (например, вызов process_data()), но входные данные и проверки подтверждения идентичны.

Это дублирование пахнет довольно плохо. Но кажется правильным хотеть проверить взаимодействия компонентов. Какие варианты позволят избежать такого дублирования?

Answer 1

В одном тестовом наборе / классе есть метод

public void TestForFooBehaviour(IFilter filter) 
{
    /* whatever you would normally have in a test method */
}

Затем вызовите этот метод как из исходного теста на простом фильтре, так и из составного фильтра. Это также работает для абстрактных базовых классов. Очевидно, что FooBehaviour должен быть содержательным описанием аспекта фильтров, которые вы тестируете. Делайте это для каждого поведения, которое вы хотите проверить.

Если ваш язык поддерживает типизацию утки или дженерики, не стесняйтесь использовать ее, если это поможет.

Answer 2

Я спросил что-то похожее об абстрактном базовом классе и модульном тестировании, здесь есть несколько интересных моментов, которые могут оказаться полезными.

Как выполнить модульное тестирование абстрактных классов: расширить с помощью заглушек?

Answer 3

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