Начало автоматизированного тестирования

Ответ 1

Итак, для начала я хотел бы упомянуть цель автоматического тестирования. Цель состоит не в том, чтобы найти ошибки, а в том, чтобы ловить регрессии. У него действительно есть возможность иногда ловить ошибки, но в целом это довольно объемная работа по написанию и обслуживанию автоматизированного набора тестов. Если вы просто нашли ошибки, гораздо дешевле просто проверить вручную. Преимущество автоматического тестирования заключается в том, что вы можете управлять своим пакетом, когда вы делаете существенные изменения, и быть более уверенным, что вы не нарушили мир. Это регрессионное тестирование является ключом к тому, почему стоит писать автоматизированные тесты.

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

Таким образом, существует три широких уровня тестирования:

Тестирование устройств

Тестирование модулей проводится в наименьшем масштабе. Он проверяет отдельные функции и/или классы. Существует множество библиотек, которые можно использовать для модульного тестирования для разных языков. Одним из примеров для python является PyUnit.

Обычно вы выполняете модульное тестирование, записывая множество и множество тестов с малой областью. Например, если вы написали свой собственный контейнерный класс (маловероятный в python, но это простой пример), у вас будут модульные тесты для добавления элементов, удаления элементов, поиска предметов и т.д.

Тестирование компонентов

Тестирование компонентов тестирует вашу программу как отдельные компоненты. Обычно это достигается путем создания mocks других компонентов. Это также обычно делается с помощью библиотеки тестирования модулей, только с более крупными тестами. Если у вас может быть 10 или сотни модульных тестов для каждого класса (в значительной степени зависит от размера класса), у вас будет несколько тестов компонентов для каждого компонента вашей системы.

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

Тестирование системы

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

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

Совет по тестированию

Тестирование в реальном мире полностью отличается от того, что я считал тестированием до того, как попал в отрасль. Когда я учился в школе, я потратил много времени на непроизводительные вещи, которые, как я думал, были продуктивными, когда я "тестировал". Это, как говорится, здесь мой совет:

• Bucketize things, и распределите ваши усилия по ковши. Посмотрите на различные аспекты, такие как стресс, производительность, пограничные случаи, регулярный ввод, локализация, пользовательский интерфейс и все остальное, что вы можете найти с ведром. Затем решите, что стоит преследовать, а что нет. Локализация, вероятно, не будет приоритетом для хобби проекта.
• Не проверяйте вещи, чтобы проверить вещи. Прежде чем вы решите написать тест, решите, стоит ли писать. Например, если вы обнаружите, что ваш сайт выйдет из строя, если вы введете 500 000 символов в качестве входных данных, исправьте ли вы это? Я знаю, что не хотел бы, если бы это было тривиальное решение. Так что тестовый файл не стоит писать.
• Подумайте о тестируемой программе как фрагменте кода. Многие люди подписываются на представление черного ящика, где вы не должны предполагать ничего о деталях реализации, но я считаю, что это непродуктивно. Напишите тесты, которые являются средними для реализации, а также являются средними для любых будущих реализаций. Это восходит к задачам автоматических тестов, а не к обнаружению ошибок, но позже к регрессиям.
• Подумайте о пограничных случаях. Если вы пишете класс контейнера, как я упоминал ранее, вы должны думать о пустых контейнерах, контейнерах максимального размера (или максимальном размере), контейнерах с одним элементом и т.д. Должно быть несколько тестов для нормального случаев и еще несколько случаев для пограничных дел. Будьте здесь прагматичны, помните пункт 2.

Дальнейшее чтение:

• Учебник PyUnit
• Вероятно, самая лучшая тестовая книга существует

Ответ 2

Простым поиском google для 'flask test', возвращается первый элемент: http://flask.pocoo.org/docs/testing/

Для модульного тестирования я думаю, что вы можете использовать некоторую файловую систему на основе db, например SQLite3.

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

вы можете начать с некоторого онлайн-руководства о том, как писать модульные тесты, например this