Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

An Introduction to Test Driven Development Expand / Collapse
Author
Message
Posted Wednesday, January 11, 2006 5:42 PM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Sunday, July 25, 2010 12:00 PM
Points: 125, Visits: 20
Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/sPalyam/anintroductiontotestdrivendevelopment.asp






Regards,
Sudheer 

My Blog

Post #250107
Posted Thursday, February 9, 2006 7:04 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Friday, July 11, 2014 7:04 AM
Points: 144, Visits: 211
I looked at tsqlunit. With VS2005, I think it is easier to use NUnit to test our stored procedures. Here's what we've done (VB.NET code)...

1) Created an NUnit test fixture that utilizes SWC (Services Without Components) and transactions. This works for us because all of our development PCs are on Windows XP. Here's the basic transaction class.

Imports NUnit.Framework
Imports System.Transactions
Imports TrulinX.SA

Public MustInherit Class TransactionFixture
Private tx As CommittableTransaction
<SetUp()> _
Public Sub Setup()
tx = New CommittableTransaction
' Make the transaction the ambient transaction.
' ADO.NET and COM+ will automatically participate
' with this ambient transaction.
Transaction.Current = tx
End Sub

<TearDown()> _
Public Sub TearDown()
tx.Rollback()
End Sub
End Class

2) All test cases that use the database inherit from TransactionFixture. This provides automatic rollback capability.

3) It's still a lot of work to set up test data. But we don't have to worry about cleaning it up because all the work is automatically rolled back.

4) Refactor, refactor, refactor! The same Insert statement may be useful in 20 different tests. Don't copy it. Centralize it in a utility module.

Our inspiration came from "Test-Driven Development in Microsoft.NET", by James Newkirk and Alexei Vorontsov. Additional inspiration came from the many bloggers who wrote about the amazing new features in Visual Studio 2005.



Post #257034
Posted Thursday, February 9, 2006 8:01 AM


SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Monday, July 7, 2014 12:50 PM
Points: 292, Visits: 264

Don't forget these two resources:

I like to use MBUnit to run the tests in a console app that brings up a web page with the results of the test run. I haven't used TestDriven.net much yet but I plan on getting into it when I finish my degree next month and have some time to mess with it more seriously.



Bryant E. Byrd, BSSE MCDBA MCAD
Business Intelligence Administrator
MSBI Administration Blog
Post #257078
Posted Sunday, February 12, 2006 6:52 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Sunday, July 20, 2014 12:37 PM
Points: 195, Visits: 576

This "simple" example of an uppercase stored proc is a very good choice for another reason: testing just one string will not be enough. A company with users in more than one country would need to use test data in the languages of all its major customers - including those with character sets that may not even have the concept of uppercase. Collecting realistic test data could be a major effort in itself, but once that is done a TDD environment would have no problem processing it.

Although I can see the benefit of formal TDD, it does add a considerable overhead in tools, training, storage, reporting and the like. It assumes that the complex infrastructure that was in place during the initial development will still be there when version 2 comes along. This may not be the case for small to medium-size projects. Also, when the focus shifts to testability, what happens to the other "ilities" like scalability and maintainability?

Post #257768
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse