An Introduction to Test Driven Development
-
Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/sPalyam/anintroductiontotestdrivendevelopment.asp
Regards,
Sudheer
-
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.
-
Don't forget these two resources:
- MBunit (does everything NUnit does and more): http://www.mertner.com/confluence/display/MbUnit/MbUnit+Home
- TestDriven.net (Testing framework for Visual Studio): http://www.testdriven.net
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.
[font="Tahoma"]Bryant E. Byrd, BSSE MCDBA MCAD[/font]
Business Intelligence Administrator
MSBI Administration Blog -
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?
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply