Какой подход (ы) вы использовали для облегченных юнит-тестов Python в App Engine?

Question

Я собираюсь приступить к некоторым крупным проектам App Engine на основе Python, и я думаю, что мне следует проверить «мудрость толпы» Stack Overflow перед принятием стратегии модульного тестирования. У меня есть существующая инфраструктура модульного тестирования (основанная на unittest с настраиваемыми бегунами и расширениями), которую я хочу использовать, поэтому что-нибудь «тяжелое» / «навязчивое», такое как nose webtest или gaeunit не представляется целесообразным. Критические юнит-тесты в моем мировоззрении являются чрезвычайно легкими и быстрыми, те, которые выполняются за очень короткое время, так что я могу продолжать выполнять их снова и снова, не нарушая ритм своего развития (например, для другого проекта, я получаю Около 97% покрытия для проекта длиной 20 тысяч строк с несколькими десятками сверхбыстрых тестов, которые в общем случае занимают 5-7 секунд, затраченное время, для типичного прогона - это то, что я считаю достойным набором небольших, быстрых устройств. тесты). Конечно, у меня будут и более тяжелые тесты, вплоть до интеграционных тестов с селеном или ветряной мельницей, это , а не , о чем я спрашиваю ;-) - мой фокус в этом вопросе (и в большинстве моих разработок ;-) - это небольшие легкие модульные тесты, которые легко и сверхбыстро охватывают мой код, а не более глубокие.

Так что я думаю, что мне нужно, по сути, набор небольших, очень легких симуляций различных ключевых подсистем App Engine - хранилища данных, memcache, объектов запросов / ответов и вызовов обработчиков веб-приложений, обработки пользователей, почты и т. Д., примерно в этом порядке приоритета. Я не нашел именно то, что искал, поэтому мне кажется, что я должен либо положиться на mox , как я часто делал в прошлом, что в основном означает насмешку над каждой подсистемой, используемой в заданный тест и настройка всех ожиданий & c (сильный, но много работы каждый раз, и очень чувствительный к внутренностям тестируемого кода, т. е. очень «белого ящика» y), или развертывание моей собственной симуляции каждой подсистемы (и выполнение утверждает состояния моделируемых подсистем в рамках модульных тестов). Последние, кажется, осуществимы, учитывая сильную архитектуру «заглушек» на стороне Python от GAE ... но я не могу поверить, что мне нужно свернуть свою собственную, то есть, что никто еще не писал такие простые симуляторы! -) Например, для хранилища данных Похоже, мне нужна более или менее заглушка «хранилище данных в файле», которая уже является частью SDK, плюс способ пометить ее для чтения и удобные средства доступа для утверждений о состоянии хранилища данных; и так далее, подсистема за подсистемой - каждому, кажется, нужно «чуть больше», чем то, что уже есть в SDK, «расположенном поверх» существующей архитектуры «заглушек».

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

Редактировать : чтобы уточнить, если я сделаю свой бросок, я планирую использовать окурки, поставляемые SDK, где это возможно; но, например, нет заглушки для хранилища данных, которое первоначально считывается из файла, но затем не сохраняется в конце, поэтому мне нужно создать подкласс и настроить существующий (который также не предлагает особенно удобных способов сделать утверждения на его состояние - то же самое для почтовой заглушки и т. д.). Вот что я подразумеваю под «катанием своих», а не «переписыванием с нуля»! -)

Редактировать : «почему бы не GAEUnit» - GAEUnit хорош для своих собственных случаев использования, но запуск dev_appserver и просмотр результатов в моем браузере (или даже через urllib.urlopen) определенно не то, что я ' m after - я хочу использовать полностью автоматизированную настройку, подходящую для работы в рамках существующей среды выполнения тестов, основанной на расширении unittest, и без использования HTTP (упомянутая среда определяет «быстрый» тест как тот, который среди других Вещи не имеют сокетов и минимального дискового ввода-вывода - мы имитируем или имитируем их - так что с помощью gaeunit я не смог бы сделать ничего лучше, чем «средние» тесты) + нет удобного способа предварительно заполнить хранилище данных для каждого теста (и нет структуры OO, чтобы помочь настроить вещи).

Answer 1

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

Answer 2

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

Answer 3

Я использую GAEUnit для своего приложения Google App Engine и очень доволен скоростью тестов. Что мне нравится в GAEUnit, и я уверен, что Webtest это делает, так это то, что он создает свою собственную версию для заглушек всего для тестирования, оставляя ваши «живые» версии в одиночку для тестирования.

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

Answer 4

Я мог бы также добавить, что Fixture был очень полезен в моих юнит-тестах. Он позволяет создавать модели в декларативном синтаксисе, который он преобразует в хранимые сущности, которые вы можете загрузить в свои тесты. Таким образом, у вас будет один и тот же набор данных в начале каждого теста !, что избавляет вас от необходимости создавать данные вручную в начале каждого теста. Вот пример из документации по Fixture: Учитывая эту модель:

from google.appengine.ext import db

class Entry(db.Model):
    title = db.StringProperty()
    body = db.TextProperty()
    added_on = db.DateTimeProperty(auto_now_add=True)

Ваш прибор будет выглядеть так:

from fixture import DataSet

class EntryData(DataSet):
    class great_monday:
        title = "Monday Was Great"
        body = """\
Monday was the best day ever.
"""

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

class TycoonTest(unittest.TestCase):
    def setUp(self):
        # Clear out the datastore before starting the test.
        apiproxy_stub_map.apiproxy._APIProxyStubMap__stub_map['datastore_v3'].Clear()    
        self.data = self.load_data()
        self.data.setup()
        os.environ['SERVER_NAME'] = "dev_appserver"
        self.after_setUp()

    def load_data(self):
        return datafixture.data(*dset.__all__)

    def after_setUp(self):
        """ After setup
        """
        pass

    def tearDown(self):
        # Teardown data.
        try:
            self.data.teardown()
        except:
            pass

Answer 5

API SDK 1.4.3 Testbed обеспечивает простую настройку библиотек-заглушек для локальных интеграционных тестов.

Answer 6

С версии 1.3.1 SDK имеется встроенная инфраструктура для модульного тестирования .

Это только Java сейчас, но я чувствую:

1. это почти то же самое, о чем вы говорите в своем вопросе (и гораздо больше - например, при запуске теста в облаке)
2. и вполне возможно перенести \ реализовать то же самое на Python, используя SDK

Так же, как и автор этой платформы - Макс Росс , и он подробно рассказывает нам об этом в своей презентации ввода-вывода "Методы тестирования для Google App Engine"

У кого-нибудь есть обновления на эту тему?