Test Driven Development for WebServices (Using VS 2005 Team Edition) RRS feed

  • Question

     Hi Everyone,
     Currently I am doing Test Driven Development in C# . Here I am using the TRANSACTION APPROACH to maintain constant data for each test case.  So what I am doing now is

    // This is the pseudocode

    OPEN CONNECTION GLOBAL TO ALL UNIT TESTS and Open transaction for each unit test and rollback the same after each unit test.

    Begin C# Transaction (ADO.Net Transaction on the SqlConnection Object)
        UnitTest 1  --> using Visual Studio 2005 Team Edition for Software Developers
    RollBack C# Transaction


    Begin C# Transaction (ADO.Net Transaction on the SqlConnection Object)
        UnitTest 2  -->
    using Visual Studio 2005 Team Edition for Software Developers
    RollBack C# Transaction


    Now for doing TDD Approach for WebServices, I wanted to know how it can be accomplished. Would it be wise to open a transaction for each WebService's  WebMethod and rollback transaction at the end of that particular unit test.  If anyone has implemented TDD Approach for WebServices, can you post some links here or some code which shows how to implement the same.

    Thanks in  Advance.
    • Moved by Max Wang_1983 Tuesday, April 26, 2011 5:44 PM forum consolidation (From:Architecture, Tools, and Process for ISVs)
    Tuesday, January 6, 2009 3:27 PM

All replies

  • With TDD you have to think about what you are testing and why.

    Are you wanting to test the web service directly (a functional or integration test) or the business logic that sits behind it (a true unit test)

    What you appear to be doing is a functional test from what I can see above.  My question is this - if there is a problem with the network and the service fails, does that mean that your TDD tests should also fail?  I don't think it does, since you will need to fix the network to fix the problem, and not your code.  With this simple question, you can see that you need to be testing the business logic, and then possibly having one or two integration tests for later - in this way, if the business logic works but the WS call fails, then you know that it is a problem outside of your control.  There are other ways to achieve this, but personally I like to use proper unit tests and a mocking framework such as RhinoMocks to achieve it.

    In answer to your question, if the web service has to always perform its work inside of a transaction, then rolling back is okay, if it does not, and is only there for the purposes of the test, then you are creating a test that will not test all of your functionality, only the artificial case.  You need to test the functionality in the same way as it would be called in the real application.

    One other question, are you injecting the SqlConnection object into your unit tests, and hence into your code?  If so, this is very bad practice - you don't have encapsulation, one of the 5 main OO tennets.  The other thing that you're doing, is inventing an alternative code path so that you can test and roll back.  The better way would be to have Setup and TearDown in your unit tests, that run scripts on your database to do the same thing, then you are not altering code to suit your tests, and have a much better shot at testing all of your application.

    I asusme that you are using a code coverage tool as part of this effort?  If you are, you should be able to get very very close if not at 100$ coverage with true unit tests, and at best maybe 80% with functional tests.  If you believe in the 80/20 rule, then you should be scared!

    So in answer to your original question, if the web services always work in transactions, what you're suggesting is fine, if they do not, then you should find some other way to tear down the resulting data that is created by your tests.

    Hope this helps,


    MCSD, MCTS, MCPD. Please mark my post as helpful if you find the information good! http://www.consultantvault.com
    Tuesday, September 29, 2009 8:52 PM