Модульное тестирование некоторых методов веб-сервиса

Question

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

Отлично, но я думаю, что мы могли бы сделать для этого Юнит-тест. Единственное, вместо того, чтобы вводить материал в веб-форму, мы просто изменили бы значения переменных, переданные в модульный тест.

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

В итоге он скажет мне, что модульному тесту требуется слишком много времени на настройку (как я уже говорил ему, что нам нужно провести модульное тестирование), что является глупым оправданием.

Answer 1

Вы с ума сошли, если вы не тестируете свой веб-сервис, а не пишете ручное тестирование:)

По сути, веб-сервис - это API, доступ к которому осуществляется через удаленный протокол, так почему бы не протестировать его модулем?

Answer 2

Я чувствую себя немного виноватым из-за того, что оставил такой бойкий ответ, как раньше, поэтому вот более серьезный подход:

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

Это не означает, что вы не можете использовать модульное тестирование framework (например, MSTest, xUnit.net, NUnit и т. Д.) Для тестирования сервисов. Давайте сопоставим этот сценарий с разработкой одноразовой страницы aspx:

• В обоих случаях Я собираюсь предположить, что веб-служба уже развернута, настроена и работает, потому что это, вероятно, имеет место в сценарии aspx.
• В в обоих случаях вам потребуется добавить ссылку на службу в тестовый проект для создания прокси веб-службы.
• В в обоих случаях вам придется написать код, который применяет значения к параметрам запроса для методов веб-службы.
• В обоих случаях вам необходимо вызвать операции веб-службы.

Так что же отличается?

• В сценарии aspx вам нужно будет собрать значения из полей формы и назначить эти значения для параметров метода сервиса. Используя среду тестирования, вы можете записать эти значения напрямую. На самом деле проще написать автоматический тест. 1-0
• В сценарии aspx вам потребуется написать код, который будет принимать данные ответов и записывать их на веб-страницу. Напротив, в рамках тестирования вам нужно будет написать утверждения. Я бы сказал, что легче писать утверждения, но это немного субъективно, поэтому я оставлю это как ничью - все равно 1-0
• В сценарии с автоматическим тестированием вам нужно будет написать много тестов с разными значениями, так что вам нужно будет написать больше кода по сравнению с параметром aspx. 1-1
• С помощью автоматизированного набора тестов вы можете впоследствии запускать набор автоматических тестов для базы данных много раз в день без дополнительных усилий, в то время как вам потребуется вручную ввести и вручную проверить результаты в aspx. сценарий для каждого теста. Это огромная победа в тестировании. 2-1 (и это консервативно)

В заключение я бы сказал, что если вы не настаиваете на проведении реального модульного тестирования в этом случае, а просто используете инфраструктуру модульного тестирования для написания автоматизированных тестов, вам лучше воспользоваться автоматизированные тесты, чем со страницей ASPX. Усилия по разработке будут более или менее одинаковыми.

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

Удачи.

Answer 3

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

Что касается написания реального модульного теста для веб-службы, я думаю, вы уже проиграли битву на этот раз ... *

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

Как только вы доказали, что модульные тесты помогают вы быстро пишете лучший код, вы можете попробовать внедрить Test Driven Development и / или сделать проверку модульных тестов в системе контроля исходного кода и другие люди запускают их, когда они меняют код.

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

Answer 4

Если это веб-служба ASMX, вы можете попробовать включить протокол HttpPost в вашем файле Web.config:

<configuration>
  <system.web>
    <webServices>
      <protocols>
        <add name="HttpPost"/>
      </protocols>
    </webServices>
  </system.web>
</configuration>

Это включит тестовую форму для веб-службы при посещении страницы .asmx в вашем браузере. Это может не работать хорошо для сложных типов; но если у вас сложные типы, в любом случае будет проще создавать модульные тесты, чем пользовательскую форму.

Аргумент, что модульное тестирование сложнее, чем веб-форма, кажется неверным; если вы разрабатываете форму, вам все равно нужно написать код клиента веб-службы, в дополнение к созданию самой страницы.

Answer 5

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

Просто сделайте это обычной практикой для следующих проектов, которые вы делаете TDD. После того, как вы проверили весь свой модуль кода, вы можете реализовать некоторые виды функционального тестирования с помощью таких инструментов, как JMeter и Selenium .

Answer 6

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

Выезд SoapUI . Он потребляет ваш WSDL и позволяет вам играть с запросами xml. Очень легко подключиться к веб-сервису, чтобы проверить его, если все, что им нужно, это POC.

Answer 7

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

Вы можете выполнить модульное тестирование для полного удовлетворения процесса разработки. Хорошей идеей является то, что юнит-тест должен выполнять тот, кто написал код метода class / function / web.

Дайте мне знать, если у вас возникнут вопросы.

Answer 8

Вместо этого вы можете написать простой тест .NET (или Java), который вызывает веб-сервис и проверяет различные сценарии, наряду с очевидным преимуществом (это можно проверить), у вас также будет автоматизированный способ проверки его функциональности.

Время, «потраченное» на написание модульных тестов, будет восстановлено на время, сэкономленное на тестировании одного и того же сценария снова и снова вместо того, чтобы просто запускать автоматические тесты.

Если ваш начальник не убежден в этом, отправьте ему исследования, которые показывают TDD / эффективность модульных тестов .

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