Как получить фактический запрос на пирамиду при модульном тестировании

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

Я вижу, что у Pyramid есть тестовый модуль с DummyRequest но это пустое, и, очевидно, если я DummyRequest это в представления, это не сработает, потому что оно не заполнено атрибутами, которые запрос будет иметь во время работы.

Итак, вопрос в том, как передать запрос, который во время тестирования выглядит как запрос во время выполнения?

4 Solutions collect form web for “Как получить фактический запрос на пирамиду при модульном тестировании”

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

 def main(): config = Configurator() config.add_route('user', '/users/{uid}') return config.make_wsgi_app() @view_config(route_name='user', renderer='user_template.mako') def user_view(request): uid = request.matchdict['uid'] user = find_user(request, uid) if user is None: raise HTTPNotFound return {'user': user} def find_user(request, uid): return request.db.query(User).filter_by(id=uid).first() 

Отлично, так что это реальный вид, и вы заметите, что для запроса требуется только 2 атрибута, matchdict и db . Хорошо, мы можем это сделать:

 class Test_user_view(unittest.TestCase): def test_it(self): req = DummyRequest() req.db = DummyDB() req.matchdict = {'uid': '3'} result = user_view(req) self.assertEqual(result['user'].id, 3) 

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

Другие ответы здесь касаются функционального тестирования более тщательно, и вы должны определенно взглянуть на использование WebTest, чтобы помочь обеспечить, чтобы все ваше приложение работало так, как вы ожидаете, но это не относится к единичному тесту.

Если вы еще этого не сделали, ознакомьтесь с инструкцией по тестированию Pyramid vs integration vs и тестирования Pyramid . ИМХО, начиная с функциональных тестов, в отличие от единичных тестов с DummyRequest, во многих случаях дает лучшие результаты (т. Е. Проще реализовать и поддерживать). Я бы рекомендовал использовать либо Webtest (примеры в документах pyramid), либо библиотеки Selenium (или их комбинацию). Использование webtest позволит вам протестировать основные функции, и тесты, как правило, будут работать быстрее, чем Selenium. Selenium может фактически запускать браузеры и обеспечивает более подробный контроль. Поскольку он запускает браузер, тесты на селен, как правило, занимают больше времени. Я думаю, что хорошее эмпирическое правило состоит в том, что если вам просто нужно базовое тестирование (например, если вы загружаете конкретную страницу), тогда придерживайтесь Webtest. Если ваш тест требует большего контроля над браузером (например, отладки javascript), попробуйте Selenium. Ознакомьтесь с приведенными выше документами, например, о том, как тестировать эти библиотеки.

Я думаю, что ответ Брайана хорош, но добавил бы, что «Write As Many Easable Testable Code As Possible» – полезная мантра. В той степени, в которой вы можете создавать функциональные возможности модульных и писать переносные библиотеки, которые легко можно тестировать с помощью средств, не зависящих от запросов, с которыми вы знакомы, вы будете довольны.

Функциональные тесты на порядок тяжелее и беспорядочно медленнее и менее приятны, чем модульные тесты; Webtest, как сказал Брайан, – это то место, где он находится за пирамидой. Селен еще на порядок более тяжелый и беспорядочный и медленный. Быть осторожен; если ваши тесты полагаются на фактические данные, они будут ломаться во времени с изменением данных. Издевательская и хорошая фиктивная информация может помочь в этом. Используйте более сложные и более сложные формы тестирования, если это необходимо, но не только для удовольствия – вы можете в какой-то степени использовать свою архитектуру, чтобы уменьшить ее необходимость.

Чтобы ответить на вопрос «как вы»: если у вас есть что-то вроде Webtest, вы просто выполните некоторую настройку, а затем сделаете что-то вроде

 response = app.get('/form.html') 

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

Вы можете создать «поддельный» запрос, подобный этому в функции setUp:

 request = testing.DummyRequest() request.errors = errors.Errors([]) request.validated = {} 

Затем в одном из ваших тестов задайте параметры, с которыми вы хотите протестировать. Как это:

 request.GET['app_id'] = 'xxxxxxxxx' valid_register(request) self.assertTrue('app_id' in request.validated) 

Надеюсь это поможет

Python - лучший язык программирования в мире.