Я бы порекомендовал протестировать такой кусок кода с помощью интеграционного тестирования, потому что нет смысла тестировать его с помощью модульного тестирования. В вашей функции file_verify
преобладают взаимодействия с зависимыми компонентами. Подумайте, какие ошибки вы, возможно, захотите найти:
open
, вызванные с неправильными аргументами (возможно, orig_pdf
не содержит допустимых символов или не является строкой, или, возможно, 'rb'
не является правильно сформированные или неправильно выбранные режимы файлов) open
вызывается с аргументами в неправильном порядке, аргументы отсутствуют, может быть, неправильная функция в целом - скорее это od.fdopen
? PyPDF2.PdfFileRead
вызывается с неверным аргументом, например, может ожидать, что имя файла, а не файл PyPDF2.PdfFileRead
выдает исключение, отличное от ожидаемого - ...
Эти ошибки могут При юнит-тестировании его не найти, так как при юнит-тестировании вы стремитесь найти ошибки в изолированном коде. Это означает, например, что вы используете тестовый double (заглушка или макет или что-то подобное) для функции open
вместо реальной функции open
. Ваша замещенная функция open
будет использоваться для проверки, вызывает ли тестируемый код функцию open
в соответствии с вашими (возможно, ошибочными) предположениями о том, как ее следует вызывать.
Чтобы сделать пример более конкретным, если вы предполагаете, что режимы файлов должны быть 'rb'
, ваши тесты с подставленным open
проверят, что вы передали 'rb'
в качестве аргумента open
. Однако, если ваше предположение было неверным, ваши юнит-тесты не помогут вам обнаружить неправильное предположение. Вместо этого, тестирование против действительной функции open
покажет вам, например, если ваш аргумент режимов был искажен, а тестирование против действительного PyPDF2.PdfFileRead
может показать, что функция на самом деле требует записываемого файла.