Написание модульного теста для функции, которая проверяет, является ли файл PDF или нет? - PullRequest
0 голосов
/ 22 января 2020

Я пишу, чтобы написать тестовые примеры для моего проекта и относительно новый для этого. У меня есть функция, которая проверяет, является ли данный файл PDF или нет (функция ниже):

def file_verify(orig_pdf):
     try:
         read_pdf = PyPDF2.PdfFileRead(open(orig_pdf,'rb'))
     except PyPDF2.utils.PdfReadError:
         return orig_pdf, "error: Invalid PDF is not supported!"
     else:
         return orig_pdf, os.path.basename(orig_pdf) + "is of PDF file format"

Теперь, как бы написать модульный тест для этой функции в python, чтобы убедиться, что она работает правильно ?

Редактировать: мне удалось написать функцию модульного тестирования (на основе информации, которую я получил онлайн), например:

testdata_filename = 'my pdf location'

class TestVerifyPDF(unittest.TestCase):

   def setUp(self):
       self.testfile = open(testdata_filename)
       self.testfile = self.testfile.read()

   def tearDown(self):
       self.testfile.close()

   def test_pdf(self):
       <test here>

1 Ответ

0 голосов
/ 24 января 2020

Я бы порекомендовал протестировать такой кусок кода с помощью интеграционного тестирования, потому что нет смысла тестировать его с помощью модульного тестирования. В вашей функции 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 может показать, что функция на самом деле требует записываемого файла.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...