locked
Test Driven Development using TRANSACTION APPROACH (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

    etc..

    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.

    Tuesday, January 6, 2009 3:16 PM

Answers

  • Hi,
    I recently came across something which can handle transactions over webservice, which is nothing but enclosing the WebService inside a COM+ transaction using System.EnterpriseServices. The Below link talks about the same.

    http://weblogs.asp.net/rosherove/articles/DbUnitTesting.aspx

    But in this approach, I cannot put a breakpoint in my visual studio  2005 . I believe this is because the entire asp.net webservices is encompassed inside a COM+ transaction for which we cannot put a breakpoint using visual studio 2005.

    I am using Visual Studio 2005 Team Edition for Software Developers and my Database is SQL 2005 .
    Please let me know your comments on the same.
    Friday, January 9, 2009 7:23 AM

All replies

  • What kind of WebServices -- older ASMX based services or WCF services?

    In both cases using this approach may be hard to do.

    For ASMX, for instance, there is no way to 'flow' a transaction from your client-side testing environment into the ASMX web method.  Therefore, the method would not be transactional and any data it touched would not be rolled back.

    WCF does have a way to flow transactions -- however it only allows flow on the methods which are marked as such.  This means that if your methods are not marked for TransactionFlow, then again, you would encounter the same issue as the ASMX services.

    Additionally, if you instead decided to modify the service's method itself (no need to flow) well then you're modifying code in the service and not testing exactly what will be in production.

    One method we typically use is that we clear the database/tables/etc (typically very quick and lightweight) at the end of each test. This would negate the need to depend on transaction rollbacks for cleanup
    Friday, January 9, 2009 2:54 AM
    Moderator
  • Hi,
    I recently came across something which can handle transactions over webservice, which is nothing but enclosing the WebService inside a COM+ transaction using System.EnterpriseServices. The Below link talks about the same.

    http://weblogs.asp.net/rosherove/articles/DbUnitTesting.aspx

    But in this approach, I cannot put a breakpoint in my visual studio  2005 . I believe this is because the entire asp.net webservices is encompassed inside a COM+ transaction for which we cannot put a breakpoint using visual studio 2005.

    I am using Visual Studio 2005 Team Edition for Software Developers and my Database is SQL 2005 .
    Please let me know your comments on the same.
    Friday, January 9, 2009 7:23 AM
  • That's certainly an interesting use of COM+ which never occured to me :)  Generally this would probably work fine.  Typically our guidelines are that methods (be they normal or web) should be designed with transactions in mind or they shouldn't be.  Making methods which don't expect transactions to be present transactional may have interesting side effects (it'll depend on the code itself).

    I'm not sure about your breakpoint issue as I've never/seen heard that issue here.  I'll ask around and if I find anything I'll come back and reply to this thread.
    Friday, January 9, 2009 6:36 PM
    Moderator