Как использовать контроллер Spring MVC в качестве поддельной конечной точки для интеграционного теста?
У меня есть служба, которая обращается к сторонней конечной точке с помощью java.net.URLConnection. В рамках интеграционного теста, использующего эту службу, я хотел бы использовать поддельную конечную точку моей собственной конструкции.
Я сделал контроллер Spring MVC, который имитирует такое поведение конечной точки, которое мне требуется. (Я знаю, что эта конечная точка работает так, как ожидалось, поскольку я включил ее в конфигурацию сервлета моего веб-приложения и ударил по ней из браузера после запуска).
Мне трудно понять, как я могу получить эту подделку. конечная точка доступна для моего интеграционного теста.
Есть ли какая-то особенность весеннего теста, которая помогла бы мне здесь? Нужно ли мне каким-то образом запускать сервлет в начале моего теста? Есть ли какие-то другие решения полностью?
3 ответа:
Использовать контроллер Spring MVC в качестве поддельной конечной точки-плохая идея. Нет способа просто иметь контроллер, доступный для интеграционного теста, и запуск сервлета только с этим контроллером наряду с тем, что вы тестируете, требует большой конфигурации.
Гораздо лучше использовать насмешливый фреймворк, такой как MockServer (http://www.mock-server.com/) для создания поддельной конечной точки. MockServer должен быть достаточно мощным, чтобы покрыть даже сложные ответы от подделки конечная точка, с относительно небольшой настройкой.
Во-первых, я думаю, что мы должны правильно подобрать терминологию. Существует две основные группы "поддельных" объектов в тестировании (упрощенных): макет, который возвращает предопределенные ответы на предопределенные входные данные, и заглушки, которые являются упрощенной версией объекта, с которым взаимодействует тестируемая система. В то время как макет в основном ничего не делает, кроме как предоставляет ответ, заглушка может использовать живой алгоритм, но не хранить его результаты в базе данных или отправлять их клиентам по электронной почте, например. Я не эксперт. в тестировании, но эти два поддельных объекта, скорее, будут использоваться в блоке и в зависимости от их объема в приемочных испытаниях.
Таким образом, ваш sut взаимодействует с удаленной системой во время интеграционного теста. В моей книге это идеальное время, чтобы действительно проверить, как ваше программное обеспечение интегрируется с другими системами, поэтому ваше программное обеспечение должно быть протестировано против тестовой версии удаленной системы. В случае, если это невозможно (у них может не быть тестовой системы), вы концептуально находитесь в некотором роде беда. Вы можете формировать заглушку или макет только так, как вы ожидаете, что он будет работать, очень похоже на ту часть программного обеспечения, которую вы написали для связи с этой удаленной службой. Это оставляет за скобками некоторые важные вещи, которые вы хотите проверить с помощью интеграционных тестов: была ли клиентская сторона реализована правильно, чтобы она работала с живым сервером. Нужно ли нам разрабатывать обходные пути, поскольку на стороне сервера есть ошибки реализации? В каком масштабе будет осуществляться связь с удаленной системой производительность нашего программного обеспечения? Работают ли наши учетные данные для аутентификации? Работает ли механизм аутентификации? Каковы технические и концептуальные последствия этих коммуникационных отношений, о которых до сих пор никто не думал? (Поверьте, последнее будет происходить чаще, чем вы могли бы ожидать!)
Вообще говоря: что произойдет, если вы выполните интеграционные тесты против макета или заглушки, это то, что вы протестируете против своего собственного понимания того, как реализовать клиент и серверную сторону связи, и вы не проверяете, как ваш клиент работает с реальным удаленным сервером или, по крайней мере, лучшей вещью рядом с этим, тестовой системой. Я могу сказать вам по опыту: никогда не делайте предположений о том, как должна вести себя удаленная система-проверьте ее. Даже если речь идет о сервере JMS: протестируйте его!
В случае, если вы работаете на компанию, тестирование против предоставленной тестовой системы еще более важно: если ваше программное обеспечение работает против тестовой системы, и вы можете доказать это (selenium-хороший верьте или нет) и ваше программное обеспечение не работает с живой версией, у вас есть ситуация, которую я называю "instablame": сразу видно, что это не ваша вина, что программное обеспечение не работает. Я сам ненавижу указывать пальцем до мозга костей, но большинство костюмов склонны спрашивать: "Кто виноват?"даже раньше "мы можем исправить это немедленно?"и задолго до этого" как мы можем решить эту проблему?". И есть специальная группа исков, которая называется адвокатами ... ;)
Если вам абсолютно необходимо использовать эти заглушки во время ваших интеграционных тестов, я бы создал для них собственный проект (скажем, "MyProject-IT-Stubs") и построил и запустил последнюю версиюMyProject-IT-Stubsперед запуском IT моего основного проекта. При использовании maven вы можете создатьMyProject-IT-Stubsс упаковкойwar, вызвать ее в качестве зависимости на этапе предварительного тестирования интеграции и запустить причал для этой войны на том же этапе. Затем ваши интеграционные тесты запускаются, успешно или нет, и вы можете снесите причал на этапе постинтеграционных испытаний.ИМХО лучший способ организовать свой проект с maven - это иметь проект с тремя модулями:
Я уверен, что соответствующие варианты существуют дляMyProject,MyProject-IT-StubsиMyProject-IT(объявляя зависимости отMyProjectиMyProject-IT-Stubs. Это позволяет сохранить ваши проекты в чистоте и порядке, а заглушки не загрязняют ваш проект. Вы также можете подумать об организацииMyProject-IT-Stubsв модули, по одному для каждой удаленной системы, с которой вам нужно поговорить. Как только у вас появится тестовый доступ, вы можете просто деактивировать систему. соответствующий модуль вMyProject-IT-Stubs.InsertYourBuildToolHere.