Вы бы назвали это (из книги «Выполнение кода») модульным тестом, интеграционным тестом или чем-то еще?

Question

В «Своде кода» Стива Макконнелла он описывает тестирование программы шифрования:

Я установил генератор тестовых данных, который полностью использовал шифрование и дешифрование частей программы. Он генерировал файлы случайных символы в случайных размерах. [...] Для каждого случайного случая он генерировал две копии случайного файла, одна зашифрованная копия, повторная инициализация расшифровывал копию, а затем сравнивал каждый байт в расшифрованная копия в зашифрованную копию. Если какие-либо байты были другими, Генератор распечатал всю информацию, необходимую для воспроизведения ошибки.

Этот тест исчерпывающе проверяет «модуль» шифрования, а также выполняет некоторые проверки других модулей - например, для доступа к файлам и управления памятью.

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

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

Как бы вы классифицировали тесты, подобные этому?

Answer 1

Это определенно , а не модульный тест , поскольку

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

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

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

Для хорошо разработанных тестов интеграционные тесты должны быть сосредоточены на взаимодействии трех блоков.Подробная функциональность каждого устройства должна была быть проверена уже в модульных тестах.Возвращаясь к цитате, которую вы дали из «Завершенного кода» Стива Макконнелла, я бы предпочел провести рандомизированный тест шифрования, высмеяв блок доступа к файлу, а затем в тесте интеграции не нужно проверять основные функции блока шифрования, а толькопротестировать пару файлов (для ситуаций, таких как пустой файл; тривиально зашифрованный файл, например, содержащий только «a»; трудно кодируемый, например, уже зашифрованный файл; очень большой файл; ...).

Короче: Тест Стива МакКоннелла представляет собой смесь единичного и интеграционного теста , наверное, именно поэтому вы задали этот вопрос ...

Answer 2

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

В принципе, модульный тест не должен выполнять никакого кода из проекта, кроме тестируемого модуля. И возможно некоторые другие модули, которые независимо тестируются без ссылки на тестируемый модуль и которые в основном предназначены для повторного использования кода. Этот тест не использует такой подход.

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

Даже вне зависимости от того, построен ли этот тест как модульный тест, может случиться так, что зашифрованный «модуль» на самом деле вовсе не является модулем, а набором частей, которые сами могут быть протестированы изолированно. Добавив больше инъекций зависимостей или иным образом переработав код, вы можете превратить менее тестируемую систему в более тестируемую систему и, следовательно, превратить часть того, что раньше было модульными тестами, в интеграционные тесты. Мы не знаем, насколько тестируем этот код на самом деле. Поэтому, возможно, вы могли бы описать это как интеграционный тест модуля шифрования. Похоже, что это не стало результатом систематической попытки тестирования интеграции, поэтому было бы немного ошибочно называть это так.

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

Лично я не думаю, что таксономия тестирования чрезвычайно важна, за исключением , что вы не должны обманывать себя, что ваши тесты лучше, чем они есть на самом деле, думая, что вы "тестировали модуль" все, когда на самом деле у вас нет. Я ожидаю, что если вы общаетесь с большой группой по тестированию, терминология становится более важной, потому что все должны знать, о чем они говорят. Но самая большая команда тестировщиков, с которой я когда-либо работал, насчитывает всего 4 или 5 человек.