Как сделать интеграционное тестирование для (Angularjs) веб-приложений
Во время запуска Tomcat механизм поставщика услуг сканирует драйверы базы данных в папке $CATALINA_BASE/lib для их регистрации. Но этот процесс не выполняется для каждого веб-приложения.
Таким образом, веб-приложения, которые имеют драйверы базы данных в своем каталоге
blockquote>WEB-INF/lib, не могут полагаться на механизм поставщика услуг и должны явно регистрировать драйверы.Подробнее в Apache Tomcat 8 - JNDI Datasource HOW-TO .
5 ответов
Вот подход для написания интеграционных тестов для вашего Angular кода. Ключевой концепцией является структурирование вашего кода таким образом, чтобы вы могли вызывать различные функции способом, очень похожим на то, как он используется в пользовательском интерфейсе. Однако для достижения успеха важно правильно отделить ваш код:
Подробнее здесь: http://www.syntaxsuccess.com/viewarticle/angular-integration-tests
Я думаю, что ответил на тот же вопрос в группе Google Protractor. Я во многом согласен с тем, что вам не нужен сервер, а нужно, чтобы весь мой тестовый код находился в одном месте (в Protractor) и не делился между Protractor и браузером. Чтобы сделать это, я взял дело в свои руки и разработал прокси для службы $ httpBackend, которая работает в Protractor. Это позволяет настроить службу $ httpBackend так, как если бы она работала в Protractor. Я работал над этим уже некоторое время, и на данный момент он достаточно полнофункциональный. Было бы здорово, если бы вы посмотрели и дали мне знать, если я что-то упустил.
Это отличный вопрос, который не имеет ничего общего с конкретным инструментом. Мне пришлось столкнуться с той же проблемой в большом проекте «с нуля» (то есть с нуля).
Здесь существует проблема со словарем: слово «макет» используется повсеместно, а то, что вы называете «интеграционным тестом», больше означает «полное сквозное автоматизированное функциональное тестирование». Не обижайтесь, просто четкая формулировка поможет решить проблему.
Вы на самом деле предложили правильный ответ: # 2 заглушите остальной сервер. # 1 выполнимо, но скоро его будет слишком сложно разрабатывать и поддерживать, # 3 - отличная идея, но не имеет ничего общего с тестированием пользовательского интерфейса и его проверкой.
Чтобы добиться высокой надежности вашего внешнего интерфейса, независимо от вашего внутреннего, просто заглушите остальной сервер, то есть разработайте глупый простой REST-сервер, который будет идемпотентным, т.е. е. ВСЕГДА ответит на одно и то же HTTP-запрос. Соблюдение принципа идемпотентности сделает разработку и тестирование очень и очень простым, чем любой другой вариант.
Затем для одного теста вы проверяете только то, что отображается на экране (тестирование сверху) и что отправляется на сервер (тестирование снизу), так что полный стек пользовательского интерфейса тестируется только один раз.
Полный ответ на этот вопрос заслуживает целой статьи в блоге, но я надеюсь, что вы можете почувствовать, что делать из того, что я предлагаю.
С наилучшими пожеланиями
Это отличный вопрос. Вот как я бы это сделал:
Поскольку у вас уже есть угловые модульные тесты для соответствующих директив и модулей, это прекрасно.
Еще одна отличная вещь - это то, что тесты интеграции вашего сервера обращаются к реальной базе данных, а также проверяют работу остальных API через http.
Так почему бы просто не добавить несколько высокоуровневых интеграционных тестов, которые одновременно включают в себя angular и ваш сервер.
Если вы можете избежать насмешек, почему бы не сохранить работу, чтобы сохранить дополнительный код, если это возможно.
Также хорошее чтение: http://blog.ericbmerritt.com/2014/03/25/mocking-is-evil.html
По моему мнению, надругаться над сервером REST - лучший, более чистый вариант. Попробуйте Mountebank ( http://www.mbtest.org ). Удивительный инструмент службы виртуализации.