Должны ли мы unit test веб-службы?

Должны ли мы unit test веб-службы или действительно смотреть на unit test код, который веб-служба вызывает для нас, и оставить веб-службу в покое или, по крайней мере, до тестирования интеграции и т.д.??

EDIT: Дальнейшие разъяснения/мысли

Моя мысль заключается в том, что тестирование веб-сервиса - это действительно интеграционное тестирование, а не модульное тестирование? Я спрашиваю, потому что наш веб-сервис на этом этапе (в разработке) закодирован таким образом, что нет способа unit test вызываемого кода. Поэтому мне интересно, стоит ли /smart реорганизовать его сейчас, чтобы иметь возможность unit test кода, свободного от веб-службы? Я хотел бы знать общий консенсус относительно того, важно ли разделять эти два или действительно ли это нормально для unit test веб-службы и называть его хорошим/мудрым.

Если я их отделил, я бы посмотрел, чтобы проверить оба, но я просто не уверен, что разделение стоит того. Моя догадка в том, что я должен.

Ответ 1

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

Ответ 2

Почему бы не обойтись? Вы можете unit test код веб-службы, а также unit test его с точки зрения клиента веб-службы.

Ответ 3

Мы делаем оба.

Мы unit test различные элементы кода.

Кроме того, мы используем структуру unit test для выполнения тестов против веб-службы в целом. Это довольно сложно, потому что мы должны создавать (и загружать) базу данных, запускать сервер и выполнять запросы на этот сервер.

Ответ 4

В моей концепции WS - всего лишь просто инкапсуляция метода объекта централизованного бизнес-уровня, другими словами, веб-метод - это всего лишь "затвор" для доступа к методам глубже в модели.

Когда первый сказал, я делаю обе операции:

Внутри сервера я создаю приложение Winform, которое выполняет Load Testing в методе бизнес-уровня.
За пределами сервера (а именно от компьютера из локальной сети, где работает веб-приложение), я создаю тестер (Winform или Web), который потребляет WS, делая это путем тестирования нагрузки.

Этот способ я могу оценить эффективность моего решения, рассматривая и отбрасывая "Эффект Web" (т.е. время для перемещения данных и достижения WS, создания объекта WS и т.д.).

Все сказанное выше, конечно, ИМХО. По крайней мере, это очень помогло мне!

Хадж.-

Ответ 5

Тестирование API веб-сервиса легко (он получил API) и ценен. Это не unit test, хотя - это тест "интеграция", "подсистема" или "система" (зависит от того, кого вы спрашиваете).

Нет необходимости откладывать тестирование до какого-то магического периода, называемого "интеграционным тестированием", но просто попробуйте провести простые тесты и воспользуйтесь преимуществом раньше.

Ответ 6

Если вы можете, попробуйте использовать свой веб-сервис, используя некоторые средства разработки, которые будут использовать ваши клиенты (Delphi, С#, VB.Net, ColdFusion, ручной XML и т.д.). Разумеется, разумно.

1) У разных инструментов могут быть проблемы с потреблением вашего веб-сервиса. Лучше для вас выполнить это до ваших клиентов.

2) Если у клиента возникает проблема, вы можете легко доказать, что ваш веб-сервис работает должным образом. В прошлом году или около того, это остановило палец, указывающий на его пути, по крайней мере, дюжину раз.

Худшим был разработчик в другом часовом поясе, который вручную обрабатывал XML-запросы SOAP и анализировал ответы. Каждый раз, когда он сталкивался с проблемой, он настаивал, чтобы это было на нашей стороне и требовало (серьезно), чтобы мы доказывали обратное. Я сделал мертвое простое приложение Delphi для использования веб-службы, продемонстрировав, что методы работали как ожидалось и даже отображали XML для каждого запроса и ответа.

Ответ 7

Мне нравится идея написания модульных тестов, которые вызывают ваш веб-сервис через один из его открытых интерфейсов. Например, данный веб-сервис WCF может выставлять HTTP, TCP и "web" привязки. Такие модульные тесты доказывают, что веб-сервис можно вызвать через привязку.

Тестирование интеграции включало бы тестирование всех привязок службы, тестирование с конкретными сценариями клиента и с конкретными клиентскими инструментами. Например, было бы важно показать, что клиент Java может быть создан с помощью IBM Rational Web Developer, который может получить доступ к службе при использовании WS-Security.

Ответ 8

обновленный вопрос.

Тестирование интеграции и модульное тестирование только внешне похожи, поэтому да, они должны выполняться и рассматриваться отдельно.

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

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