Поблочное тестирование некоторые методы веб-сервиса
В дополнение к тестированию, что функция возвращает дату в желаемом диапазоне, Вы хотите удостовериться, что результат хорошо распределяется. Тест, который Вы описываете, передал бы функцию, которая просто возвратила дату, которую Вы представили!
Так в дополнение к вызыванию функции многократно и тестированию, что результат остается в желаемом диапазоне, я также попытался бы оценить распределение, возможно, путем помещения результатов в блоки и проверки, что блоки имеют примерно равные количества результатов после того, как Вы сделаны. Вам, возможно, понадобятся больше чем 100 вызовов для получения стабильных результатов, но это не походит на дорогое (мудрое время выполнения) функция, таким образом, можно легко выполнить его для нескольких повторений K.
у меня была проблема прежде с неоднородными "случайными" функциями.. они могут быть реальной болью, на это стоит протестировать рано.
8 ответов
I feel a little bit guilty about leaving such a glib answer as I did before, so here's a more serious take on it:
Let's examine what it would take to unit test the service. A real unit test is an automated test that tests a single unit (in your case that would the web service without any backend systems such as databases etc.). As others have pointed out, proper unit testing of the service is probably too late in this case.
That doesn't mean that you can't use a unit testing framework (such as MSTest, xUnit.net, NUnit, etc.) to drive your service tests. Let us contrast that scenario to developing a throw-away aspx page:
- In both cases I am going to assume that the web service is already deployed, configured and running, because that would probably be the case in the aspx scenario.
- In both cases you would have to add a service reference to the test project to generate a web service proxy.
- In both cases you would have to write code that applies values to the request parameters for the web service methods.
- In both cases you need to invoke the web service operations.
So what's different?
- In the aspx scenario, you will need to collect values from form fields and assign those values to to the service method paramters. Using a testing framework, you can write those values directly. It's actually easier to write the automated test. 1-0
- In the aspx scenario, you would need to write code that takes the response data and write it to the web page. In contrast, with a testing framework, you will need to write assertions. I would claim that it's easier to write assertions, but that's a bit subjective so I'll leave this one as a tie - still 1-0
- In the automated test scenario, you will need to write many tests with different values, so that's more code you will need to write compared to the aspx option. 1-1
- With an automated test suite, you can subsequently run the automated test suite against the database many times a day with no additional effort, whereas you would need to manually input and manually verify the results in the aspx scenario for every test run. That's a huge win in testing effort. 2-1 (and that's conservative)
In conclusion, I would say that if you don't insist on doing real unit-testing in this case, but simply utilize a unit testing framework to write automated tests, you should be better off with the automated tests than with the aspx page. The development effort will be more or less the same.
For your next project, you can then see if you can use TDD from the beginning, but that's another battle.
Good luck.
Вы сошли с ума, если не тестируете свою веб-службу вместо того, чтобы писать программу ручного тестирования :)
По сути, веб-служба - это API, доступ к которому осуществляется по удаленному протоколу , так почему бы не протестировать его?
Если это веб-служба ASMX, вы можете попробовать включить протокол HttpPost в своем Web.config:
<configuration>
<system.web>
<webServices>
<protocols>
<add name="HttpPost"/>
</protocols>
</webServices>
</system.web>
</configuration>
Это включит тестовую форму для веб-службы при посещении страницы .asmx в вашем браузере. Это может не работать для сложных типов; но если у вас есть сложные типы, в любом случае будет легче построить модульные тесты, чем пользовательскую форму.
Аргумент, что модульное тестирование сложнее, чем веб-форма, кажется неверным; если вы разрабатываете форму, вам все равно придется написать код клиента веб-службы в дополнение к созданию самой страницы.
Ваш начальник может пожелать подтвердить, что веб-службу можно вызвать со страницы .aspx , а также проверить некоторые значения. (Нужен ли ему пример кода вызова, который кто-то другой может использовать для создания настоящей веб-страницы?) Если ваша веб-служба вызывает какие-либо внешние службы и / или использует базу данных, в любом случае будет сложно написать для нее автоматические модульные тесты.
Что касается написания настоящего модульного теста для веб-службы, я думаю, что на этот раз вы уже проиграли битву ...
В следующий раз попробуйте написать модульные тесты для каждого метода, который вызывает веб-сервис, непосредственно перед или сразу после того, как вы напишете метод. Нет необходимости даже говорить своему начальнику, что вы это делаете, так как это приведет к более быстрой разработке рабочего кода.
После того, как вы убедились, что модульные тесты помогают , вы быстро напишите лучший код, вы можете попробовать внедрить разработку через тестирование и / или проверить модульные тесты в системе управления исходным кодом и другими людьми. запускать их, когда они изменяют код.
Вы всегда можете провести некоторое время сегодня вечером, после того как ваш босс уйдет домой, пытаясь написать модульные тесты. Тогда говорите ему, что вы сделали, только когда он спросит, почему в вашем коде нет ошибок.
Это битва, которую вы обязательно проиграете. Вы должны поставить себя на место босса. Есть проекты, где модульное тестирование может занять слишком много времени, особенно в конце цикла разработки, когда все нужно завершить в спешке. TDD необходимо соблюдать с самого начала, иначе вы потеряете слишком много времени на выполнение модульных тестов после того, как уже забудете, как работает конкретный фрагмент кода (нет, комментариев обычно недостаточно).
Просто Сделайте TDD обычной практикой для следующих проектов.
Вместо этого вы можете написать простой .NET (или Java) тест, который вызывает веб-службу и проверяет различные сценарии. Наряду с очевидным преимуществом (возможность тестирования) у вас также будет автоматизированный способ проверьте его работоспособность.
Время, «потраченное впустую» на написание модульных тестов, будет восстановлено за счет времени, сэкономленного на тестировании одного и того же сценария снова и снова, вместо того, чтобы просто запускать автоматические тесты.
Если ваш босс не убежден к этому моменту он обратился к исследованиям, которые показывают эффективность TDD / модульных тестов .
Если ничего не помогает, почему бы не использовать автоматический инструмент, такой как soapUI , по крайней мере, вы избавите себя от ручного тестирования одной и той же функциональности снова и снова.
Предполагая, что вы уже проиграли битву (мы сочувствуем вам). Есть решения лучше, чем создание потребителя для веб-службы вручную.
Ознакомьтесь с SoapUI . Он использует ваш WSDL и позволяет вам играть с xml-запросами. Очень легко подключиться к веб-сервису, чтобы проверить, нужен ли им только POC.
На мой взгляд, если вы создадите страницу .aspx и получите значение из веб-формы, это будет больше тестирование в реальном времени, чем модульное тестирование. Я надеюсь, что веб-сервис уже прошел модульное тестирование организацией, которая предоставляет вам этот веб-сервис. Я думаю, вам просто нужно создать форму .aspx и делать свою работу.
Вы можете проводить модульное тестирование для удовлетворения всего процесса разработки. Это хорошая идея, что модульное тестирование должен выполнять человек, написавший код класса / функции / веб-метода.
Дайте мне знать, если у вас есть какие-либо вопросы.