using System; using System.Diagnostics; using System.Globalization; using System.IO; using System.Text; namespace Vandermotten.Diagnostics
{ ///
<summary>///
Implements a <see cref="TextWriter"/> for writing information to the debugger
log.///
</summary>///
<seealso cref="Debugger.Log"/>publicclass DebuggerWriter
: TextWriter { privatebool isOpen; privatestatic UnicodeEncoding
encoding; privatereadonlyint level; privatereadonlystring category; ///
<summary>///
Initializes a new instance of the <see cref="DebuggerWriter"/> class.///
</summary>public DebuggerWriter()
: this(0,
Debugger.DefaultCategory) { } ///
<summary>///
Initializes a new instance of the <see cref="DebuggerWriter"/> class with the
specified level and category.///
</summary>///
<param name="level">A description of the importance of the messages.</param>///
<param name="category">The category of the messages.</param>public DebuggerWriter(int level, string category)
: this(level,
category, CultureInfo.CurrentCulture) { } ///
<summary>///
Initializes a new instance of the <see cref="DebuggerWriter"/> class with the
specified level, category and format provider.///
</summary>///
<param name="level">A description of the importance of the messages.</param>///
<param name="category">The category of the messages.</param>///
<param name="formatProvider">An <see cref="IFormatProvider"/> object that
controls formatting.</param>public DebuggerWriter(int level, string category,
IFormatProvider formatProvider) : base(formatProvider)
{ this.level = level; this.category = category; this.isOpen =true;
} protectedoverridevoid Dispose(bool disposing)
{ isOpen =false; base.Dispose(disposing);
} publicoverridevoid Write(char value)
{ if (!isOpen)
{ thrownew ObjectDisposedException(null);
} Debugger.Log(level, category, value.ToString()); } publicoverridevoid Write(string value)
{ if (!isOpen)
{ thrownew ObjectDisposedException(null);
} if (value
!=null)
{ Debugger.Log(level, category, value); } } publicoverridevoid Write(char[]
buffer, int index, int count)
{ if (!isOpen)
{ thrownew ObjectDisposedException(null);
} if (buffer
== null ||
index < 0 || count < 0 || buffer.Length - index
< count) { base.Write(buffer,
index, count); //
delegate throw exception to base class } Debugger.Log(level, category, newstring(buffer,
index, count)); } publicoverride Encoding
Encoding { get { if (encoding
== null)
{ encoding =new UnicodeEncoding(false, false);
} return encoding;
} } publicint Level
{ get { return level;
} } publicstring Category
{ get { return category;
} } } }

I have to give a special mention to this tool as it helps me generate scripts for my Unit Tests really quickly.  It's free at the moment, although each version has an expiration date, but it's well worth a look if you need something to quickly generate scripts.

http://www.sqlscripter.com/

It's also an example of REALLY GOOD USER INTERFACE DESIGN.  The author has taken the time to predict what you're most likely to do and wrapped up any repetitive tasks (for example logging in to the same database with the same credentials, or scripting a certain subset of tables with the same criteria).  You can tell it's a bit rough round the edges, but then it's not a commercial product yet.

Unit Testing of database applications is a large topic, so I'll concentrate on a specific scenario.

If you have the following setup:

TestFixture

• Init - populate database with default data
• Teardown - run delete script to restore the database to it's previous state.

This will be sufficient if none of our tests modify the data in between.  But we'll need to to test Create, Update and Delete methods of our business objects.

So, if one Test updates the database, but another Test is run after it which is expecting the database to be in it's original state (i.e. the state it's in straight after the TestFixture.Init() method has been called)  then we have a problem.  But we can't determine the order that the tests will run in, so what are our options?

We could partition our tests into different TestFixtures, so avoiding the problem altogether.  Or we could run the Populate and Delete scripts after EVERY test - though this is likely to be slow and will probably become impractical as our test library grows.

A good solution would be to have each test run in isolation, where changes to the database are rolled back after each test is run - this way the database can be updated in one test but returned to it's original state before the next test runs.

We can do this by using the TransactionScope object, like so:

          [Test] privatevoid TestSomething()
{ using(new TransactionScope())
{ //Update
the database//Perform
Assertions } }
        

If we need to do some common initialisation of the TransactionScope object, for example setting IsolationLevel or Timeout properties, then we can wrap this up in a class as follows:

              publicclass RollbackTransaction:
IDisposable     {         private TransactionScope
mScope;         public RollbackTransaction()
        {             TransactionOptions
tOptions =new TransactionOptions();
            tOptions.IsolationLevel = IsolationLevel.RepeatableRead;
            tOptions.Timeout =new TimeSpan(2,
0, 0);             mScope =new TransactionScope(TransactionScopeOption.RequiresNew,
             tOptions);
        }         ///<summary>         ///Performs
application-defined tasks associated with freeing, releasing, or resetting unmanaged
resources.         ///</summary>         ///<filterpriority>2</filterpriority>         publicvoid Dispose()
        {             mScope.Dispose();
        }     }
        

and instead of using(new TransactionScope()), we would instead have using(new RollbackTransaction()).