SQLServerCentral / Discuss Content Posted by Sudheer Palyam / Article Discussions / Article Discussions by Author / An Introduction to Test Driven Development / Latest Posts

RE: An Introduction to Test Driven Development

mosaic-287947 — Sun, 12 Feb 2006 06:52:00 GMT

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?

RE: An Introduction to Test Driven Development

Tatsu — Thu, 09 Feb 2006 08:01:00 GMT

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.

RE: An Introduction to Test Driven Development

hurcane — Thu, 09 Feb 2006 07:04:00 GMT

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.FrameworkImports System.TransactionsImports TrulinX.SAPublic 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 SubEnd Class2) 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.

An Introduction to Test Driven Development

cutespn — Wed, 11 Jan 2006 17:42:00 GMT

Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/sPalyam/anintroductiontotestdrivendevelopment.asp