Не.
Не проверяйте произвольные интерфейсы и не создавайте для них макеты.
Большинство людей, похоже, считают, что тестирование разработчиком (модулем) предназначено для тестирования нетривиальных, отдельных модулей функциональности, таких как отдельный класс. С другой стороны, также важно выполнить потребительское (приемочное / интеграционное) тестирование основных подсистем или всей системы.
Для веб-службы нетривиальная единица функциональности скрыта в классах, которые фактически выполняют значимое обслуживание, за коммуникационной проводкой. Эти классы должны иметь отдельные тестовые классы разработчика, которые проверяют их функциональность, но полностью без какой-либо проводки, ориентированной на веб-сервисы. Естественно, но, возможно, не очевидно, это означает, что ваша реализация функциональности должна быть отделена от вашей реализации проводки. Таким образом, ваши разработчики (юнит-тесты) никогда не должны видеть никакой специальной коммуникационной проводки; это является частью интеграции, и ее можно рассматривать (соответственно) как проблему «представления», а не как «бизнес-логику».
Клиентские (приемочные / интеграционные) тесты должны охватывать гораздо больший масштаб функциональности, но при этом не фокусироваться на вопросах «презентации». Именно здесь широко распространено использование шаблона Facade - предоставление подсистемы с унифицированным грубым тестируемым интерфейсом. Опять же, интеграция взаимодействия с веб-сервисом не имеет значения и реализуется отдельно.
Однако очень полезно реализовать отдельный набор тестов, который фактически включает интеграцию с веб-сервисом. Но я настоятельно рекомендую не тестировать только одну сторону этой интеграции: тестировать ее из конца в конец. Это означает создание тестов, которые являются клиентами веб-сервисов, как настоящий производственный код; они должны использовать веб-сервисы в точности так, как это делают реальные приложения, а это значит, что эти тесты служат примерами для тех, кто должен внедрять такие приложения (например, для ваших клиентов, если вы продаете библиотеку).
Итак, зачем идти ко всем этим неприятностям?
Ваши тесты разработчика подтверждают, что ваша функциональность работает в малом размере, независимо от того, как к ней осуществляется доступ (независимо от уровня представления, поскольку все это находится внутри уровня бизнес-логики).
Ваши клиентские тесты подтверждают, что ваша функциональность работает в целом, опять же независимо от того, как к ней осуществляется доступ, на границе интерфейса уровня бизнес-логики.
Ваши интеграционные тесты подтверждают, что ваш уровень представления работает с вашим уровнем бизнес-логики, который теперь управляем, поскольку теперь вы можете игнорировать базовую функциональность (потому что вы отдельно протестировали ее выше). Другими словами, эти тесты ориентированы на тонкий слой симпатичного лица (GUI?) И коммуникационный интерфейс (веб-сервисы?).
Когда вы добавляете другой метод доступа к своей функциональности, вам нужно только добавить интеграционные тесты для этой новой формы доступа (уровень представления). Ваши тесты для разработчиков и клиентов гарантируют, что ваша основная функциональность не изменится и не будет нарушена.
Вам не нужны никакие специальные инструменты, такие как тестовый инструмент специально для веб-сервисов. Вы используете инструменты / компоненты / библиотеки / методы, которые вы использовали бы в рабочем коде, точно так же, как вы использовали бы их в таком рабочем коде. Это делает ваши тесты более значимыми, поскольку вы не тестируете чужие инструменты. Это экономит ваше время и деньги, поскольку вы не покупаете, не развертываете, не разрабатываете и не поддерживаете специальный инструмент. Однако, если вы тестируете через графический интерфейс (не делайте этого!), Вам может понадобиться один специальный инструмент для этой части (например, HttpUnit?).
Итак, давайте разберемся. Предположим, что мы хотим обеспечить некоторую функциональность для отслеживания ежедневного меню кафетерия (потому что мы работаем в мегакорпорации с собственным кафе в здании, как у меня). Допустим, мы нацелены на C #.
Мы создаем некоторые классы C # для меню, пунктов меню и других детальных функциональных возможностей и связанных с ними данных. Мы устанавливаем автоматическую сборку (вы делаете это, верно?), Используя nAnt, который выполняет тесты разработчика, используя nUnit, и мы подтверждаем, что мы можем создать ежедневное меню и просматривать его с помощью всех этих маленьких кусочков.
У нас есть некоторое представление о том, куда мы идем, поэтому мы применяем шаблон Facade, создавая один класс, который предоставляет несколько методов, скрывая большинство мелкозернистых фрагментов. Мы добавили отдельный набор клиентских тестов, которые работают только через этот новый фасад, как и клиент.
Теперь мы решили, что мы хотим предоставить веб-страницу нашим работникам, занятым в мегакорпоративном обучении, чтобы проверить меню современной столовой. Мы пишем страницу ASP.NET, заставляем ее вызывать наш фасадный класс (который становится нашей моделью, если мы делаем MVC) и разворачиваем ее. Поскольку мы уже тщательно протестировали класс фасадов с помощью наших пользовательских тестов, и поскольку наша отдельная веб-страница настолько проста, мы отказываемся от написания автоматических тестов для веб-страницы - ручной тест с использованием нескольких коллег по знаниям поможет.
Позже мы начинаем добавлять некоторые новые важные функции, например, возможность предварительно заказать обед на день. Мы расширяем наши детальные классы и соответствующие тесты разработчика, зная, что наши уже существующие тесты защищают нас от взлома существующей функциональности. Аналогично, мы расширяем наш класс фасадов, возможно, даже отделяя новый класс (например, MenuFacade и OrderFacade) по мере расширения интерфейса, с аналогичными дополнениями к нашим тестам для клиентов.
Теперь, возможно, изменения на веб-сайте (две страницы - это веб-сайт, верно?) Делают ручное тестирование неудовлетворительным. Итак, мы предлагаем простой инструмент, сравнимый с HttpUnit, который позволяет nUnit тестировать веб-страницы. Мы реализуем ряд интеграционных / презентационных тестов, но на основе фиктивной версии наших фасадных классов, потому что дело здесь просто в том, что веб-страницы работают - мы уже знаем, что работают фасадные классы. Тесты проталкивают данные через фиктивные фасады только для того, чтобы проверить, что данные успешно перешли на другую сторону. Ничего больше.
Конечно, наш грандиозный успех побуждает генерального директора потребовать (потребовать), чтобы мы представили веб-приложение для BlackBerrys мегакорпорации. Итак, мы внедрили несколько новых страниц и новую батарею интеграционных тестов. Нам не нужно прикасаться к тестам разработчика или заказчика, потому что мы не добавили новых основных функций.
Наконец, технический директор просит (требует), чтобы мы распространили наше приложение для кафетерия на всех работников роботов мегакорпорации - вы заметили их в последние несколько дней? Итак, теперь мы добавляем слой веб-сервисов, который взаимодействует через наш фасад. Опять же, никаких изменений в нашей основной функциональности, наших тестах для разработчиков или наших клиентских тестах. Мы применяем шаблон Adapter / Wrapper, создавая классы, которые предоставляют фасад с эквивалентным API веб-службы, и мы создаем клиентские классы для использования этого API. Мы добавили новую батарею интеграционных тестов, но они используют простой nUnit для создания клиентских API-классов, которые связываются через проводку веб-службы с API-классами сервисной стороны, которые вызывают фиктивные классы фасадов, которые подтверждают, что наша проводка работает.
Обратите внимание, что на протяжении всего этого процесса нам не требовалось ничего значительного, кроме нашей производственной платформы и кода, нашей выбранной платформы разработки, нескольких компонентов с открытым исходным кодом для автоматического создания и тестирования и нескольких четко определенных наборов тестов. Также обратите внимание, что мы не тестировали ничего, что не используем в производстве, и мы ничего не тестировали дважды.
В результате мы получили прочное ядро функциональности (уровень бизнес-логики), которое оказалось зрелым (гипотетически). У нас есть три реализации уровня представления: веб-сайт, предназначенный для настольных компьютеров, веб-сайт, предназначенный для BlackBerrys, и API веб-службы.
Теперь, пожалуйста, прости меня за длинный ответ - я устал от неадекватных ответов и не хотел их давать. И, пожалуйста, обратите внимание, что я действительно сделал это (но не для меню кафетерия).