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

Я понимаю, что важно включить тесты в исходный код. Что меня интересует, должен ли я на самом деле настроить их для установки?

Я видел по крайней мере один популярный пакет, который, кажется, делает это специально (PyHamcrest) и, по крайней мере, еще один, который делает это случайно (ведите себя).

Итак, мой (многочастный) вопрос таков:

  • Имеет ли смысл устанавливать мои пакетные тесты вместе с моими код пакета?

  • Если да, то каков вариант использования? Кто бы их использовал и для чего? То есть кто будет использовать их, которые не будут совершенно счастливы скачать исходный код распределить и запустить python setup.py test вместо этого?

  • И как они будут использовать установленные юнит-тесты? как import test; test.run() или что-то как это?

13
scanny 22 Янв 2013 в 12:57

2 ответа

Лучший ответ

После изучения этой проблемы и до тех пор, пока у кого-то более опытного не будет минуты, чтобы взвесить обратное, я понимаю, что простой ответ таков: «Нет, модульные тесты не должны устанавливаться, только включены в исходный дистрибутив » .

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

Вот как это происходит:

  1. Параметр packages=find_packages() используется в setup.py, поэтому пакеты можно найти без явного их перечисления.
  2. Папка test превращается в пакет (путем добавления __init__.py), поэтому тесты могут ссылаться на модули, которые тестируют, используя относительное именование (например, from .. import pkg.mod).
  3. setuptools устанавливает test как отдельный пакет вместе с другими в проекте. Обратите внимание, это означает, что вы можете выполнить import test в интерпретаторе python, и это работает, почти наверняка, не так, как вы предполагали, тем более что многие другие люди используют это имя для своего тестового каталога :)

Исправление заключается в использовании параметра: packages=find_packages(exclude=['test']), чтобы предотвратить установку вашего тестового каталога.

10
scanny 31 Янв 2013 в 01:44

Однако я не эксперт, я хотел бы поделиться своим мнением.

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

Кто не был бы счастлив скачать исходный код и запустить тесты? Может быть, некоторые debian пользователи, у которых пакеты извлекаются из исходников (я знаю, что вы говорите о Python, но позвольте мне немного рассказать об этом), могут иногда выходить из строя из-за некоторых странных вещей в системе.

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

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

РЕДАКТИРОВАТЬ: Может быть, будет лучше перефразировать это. Я установил бы тесты, когда вы чувствуете, что могут быть предупреждения переносимости. Я думаю, что всегда полезно проверять вещи, когда вы развертываете вещи в другой системе.

1
luk32 22 Янв 2013 в 14:07