Должны ли мы тестировать веб-сервис?

Question

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

РЕДАКТИРОВАТЬ: дальнейшие разъяснения / мысли

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

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

Answer 1

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

Answer 2

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

Answer 3

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

С первым сказанным я делаю обе операции:

1. Внутри сервера я создаю приложение Winform, которое выполняет нагрузочное тестирование по методу бизнес-уровня.

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

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

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

Хадж .-

Answer 4

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

Мы проводим модульное тестирование различных элементов кода.

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

Answer 5

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

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

Answer 6

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

1) Различные инструменты могут иметь проблемы с использованием вашего веб-сервиса. Тебе лучше столкнуться с этим раньше, чем твои клиенты.

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

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

Answer 7

Тестирование API веб-сервиса простое (у него есть API) и ценное. Однако это не модульный тест - это тест на интеграцию, подсистему или систему (зависит от того, кого вы спрашиваете).

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

Answer 8

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

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

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

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