Unit Testing Some Web Service Methods

Question

My boss wants me to create an .aspx page, textboxes for simplicity for entering credit card information so we can test out some methods in our CreditCard service.

Thats fine but I would think we could do a Unit test for this. The only thing is, instead of typing the stuff into a web form, we'd just change the variable values passed into the unit test.

Can anyone tell me if we're crazy for not doing a Unit test instead of an .aspx page for testing and entering in test data to test out some calls to some of our methods?

He'll end up telling me Unit Test takes too much time to setup (as I've tried to tell him we need to do unit testing) which is a lame stupid excuse.

Answer 1

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.

Answer 2

If it's an ASMX web service, you might try enabling the HttpPost protocol in your Web.config:

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

This will enable the test form for the web service when you visit the .asmx page in your browser. It might not work well for complex types; but if you have complex types, it'll be easier to build the unit tests than a custom form anyway.

The argument that unit testing is harder than a web form seems wrong; if you're developing a form, you have to write the web service client code anyway, in addition to building the page itself.

Answer 3

Your boss may wish to confirm that the web service can be called from an .aspx page as well as being able to try out some values. (Does he want example calling code that someone else to use to create the real web page?) If your web service calls any external services and/or uses a database it will be hard to write automated unit tests for it anyway.

As to writing a real unit test for the web service, I think you have already lost the battle this time….

Next time, try writing unit tests for each method the web services calls, just before or just after you write the method. There is no need to even tell your boss you are doing this, as it will result in producing working code quicker.

Once you have proved the unit tests help you write better code quickly you can try to introduce Test Driven Development and/or have the unit tests check into the source code control system and other people run them when they change the code.

You could always spend some of your own time tonight, after your boss has gone home, trying to write the unit tests. Then only tell him what you have done when he ask why your code has no bugs in it.

Answer 4

It is a battle you'll surely loose. You have to put yourself in your bosses shoes. There are projects where unit testing could take up too much time, especially at the end of the development cycle when everything is rushed to be completed. TDD has to be followed from the start or you will loose too much time implementing unit tests after you have already forgotten how a specific piece of code works (no, comments are usually not enough).

Just make it common practice for next projects that you do TDD. After you have all of your code unit tested you could implement some type of functional testing with tools such as JMeter and Selenium.