For the first one, a simple solution is to just script all objects in the database to a folder and add it to the source code repository (one file per object – in MS SQL Server can be done with a few clicks from SQL Server Management Studio). When there are changes, all you need to do is to repeat this process and the files will be updated. You can then review changes to database objects in the same way you review them for code files.

The second one is a little trickier. Idealy you want scripts that can be automatically used to:
- update developer database copies
- update the continuous integration database (database used for the continuous integration tests)
- update the test database
- update the production database.

There are tools that give you “diff” scripts that can be used to update a database, but, apart from the price problem, they are difficult to use for several-times-a-day automatic updates like the ones needed to update the developer copies. A second problem is that, because the developers have full freedom in their database copy, some “garbage” or unwanted changes might be picked up and included in the diff script.
The solution below is free, the updates can be run automatically whenever is necessary on any database (developer, test and even production) and ensures that the changes were really meant to be included in the update. All you need is a little discipline from the developers.

We’ll use a table in the database to store the current version. This script create this table and sets the version to 1.

-- CREATE Table [dbo].[Version]

SET ANSI_NULLS ON

GO

SET QUOTED_IDENTIFIER ON

GO

SET XACT_ABORT ON

GO

BEGIN TRAN

IF EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[Version]') AND type in (N'U'))

BEGIN

DECLARE @actual int

SELECT @actual = ISNULL(MAX(VersionNumber),0) FROM Version

RAISERROR('Update to version %d cannot be run - actual version is %d', 1, 127, 1, @actual) WITH LOG

END

CREATE TABLE [dbo].[Version](

[VersionNumber] [int] NOT NULL,

CONSTRAINT [PK_Version] PRIMARY KEY CLUSTERED

(

[VersionNumber] ASC

)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]

) ON [PRIMARY]

INSERT INTO [dbo].[Version]

([VersionNumber])

VALUES

(1)

GO

COMMIT

The next step is to define a template for an update:

-- VERSION DESCRIPTION HERE!

SET ANSI_NULLS ON

GO

SET QUOTED_IDENTIFIER ON

GO

SET XACT_ABORT ON

GO

BEGIN TRAN

DECLARE @newVersion int

SET @newVersion = -- version number here

IF NOT EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[Version]') AND type in (N'U'))

RAISERROR('Update to version %d cannot be run - actual version is 0', 1, 127, @newVersion) WITH LOG

DECLARE @actualVersion int

SELECT @actualVersion = ISNULL(MAX(VersionNumber),0) FROM Version

IF @actualVersion <> @newVersion - 1

RAISERROR('Update to version %d cannot be run - actual version is %d', 1, 127, @newVersion, @actualVersion) WITH LOG

UPDATE [dbo].[Version]

SET [VersionNumber] = @newVersion

RAISERROR('Updating to version %d...', 1, 1, @newVersion) WITH LOG

GO

-- START UPDATE

-- END UPDATE

GO

COMMIT

What this does is that it checks that the actual version in the database is the one preceding the @newVersion we want to apply. If there is no Version table or it has a different version, the script raises an error and aborts the update. If everything is ok, it applies the changes found between — START UPDATE and — END UPDATE and updates the version number.

The developers can now create update scripts using this template and save them in a “Change Scripts” folder using a naming convention like v0001.sql, v0002.sql, etc. The naming is important because we’ll rely on it to automatically run the scripts in order. The folder should be added to the code repository so everyone can easily get the latest changes.
Also, it is important that the developers take into account that the scripts will be run in production – no data loss is allowed! So no Drop and Create Table – use Alter instead!

In order to run the scripts automatically you can use the following batch files or write your own using your preferred shell.
First, a helper script – runOneSqlScript.bat – receives (in order) servername, database, sql file, output log file and a flag wether to show the output to console and calls sqlcmd passing those parameters.

rem @echo off

sqlcmd -S %1 -d %2 -i %3 -o %4 -X

IF "%5" == "N" GOTO :END

type %4

:END

rem @echo on

This second script uses the first to run all the available updates. You can pass parameters if you need to use another server or database name than the defaults.

set DBSERVER=localhost

set DBNAME=MyDB

IF "%1" == "" GOTO :STARTSQL

SET DBSERVER=%1

IF "%2" == "" GOTO :STARTSQL

SET DBNAME=%2

:STARTSQL

for %%f in ("Change Scripts\"v*.sql) do call runOneSqlScript.bat %DBSERVER% %DBNAME% "%%f" "%%f.log"

Using these, the developers can automatically apply updates to their copy of the database. The script can also be run as part of the Continuous Integration build and update the CI database copy before running the tests. And finally, the same scripts can be use to update the test and production databases. Because the developers have to take the time to create the update script, the chance of adding “garbage” changes is greatly reduced.

For the developer and test databases another important issue is the demo data – how to maintain it up to date and not have it turn into garbage. In the next part I’ll propose a solution that builds on the automatic updates presented above to mitigate this problem.

<asp:BoundField DataField=”Percentage” DataFormatString=”{0:f2}%” HeaderText=” Percentage” ReadOnly=”True” SortExpression=”Percentage” />

That’s because no matter what you put in the DataFormatString property, the text is formatted the same way (although the literal characters from outside the brackets do appear, so DataFormatString it’s not completely ignored).

The solution:

<asp:BoundField DataField=”Percentage” DataFormatString=”{0:f2}%” HeaderText=” Percentage” ReadOnly=”True” SortExpression=”Percentage” HtmlEncode=”false” />

Don’t know why…

As it turns out, if you want to show a non-modal form centered in the boundaries of its parent, in .NET 2.0, you’ll have to set its position manually.

Although the System.Windows.Forms.FormStartPosition.CenterParent works fine if you use form.ShowDialog(owner); (modal form), it doesn’t seem to make a difference when using form.Show (owner); for a non-modal form. I suspect a bug, because I didn’t find any mention of this behavior in help.

The solution:

form.StartPosition = FormStartPosition.Manual;

form.Location = new System.Drawing.Point(form.Owner.Location.X + (form.Owner.Width – form.Width) / 2, form.Owner.Location.Y + (form.Owner.Height – form.Height) / 2);

One annoying thing in SQL 2000 was that you couldn’t select TOP @n records using a variable. The options were to construct the SQL query dynamically or (if you wanted to use stored procedures) to use SET ROWCOUNT @n before the select. And of course not to forget to set it back to 0 as soon as you’re done with it.

SQL 2005 solves this problem. You can now use variables in the TOP count:

CREATE PROCEDURE GetLatestAnnouncements
@topCount int

AS
BEGIN
SELECT TOP (@topCount) * FROM Announcements

ORDER BY DateAdded DESC
END

Another handy addition is the Row_Number() function – it basically gives you the sequential number for a row in a result set. You can use it to get “pages” of records just like those you normally need in a paging DataGrid:

CREATE PROCEDURE GetAnnouncementRangeByDate
@startIndex int,
@pageSize int

AS
BEGIN

SELECT Title, [Text], DateAdded FROM
(SELECT

Row_Number() OVER (ORDER BY DateAdded DESC) as RowPosition,
Title, [Text], DateAdded FROM Announcements
) tempselect
WHERE tempselect.rowposition BETWEEN @startIndex AND @startIndex + @pageSize

END

The Web Client Software Factory provides a handy class, StateValue<T>, to use for storing values in Session. From the WCSF help:

This class supports code that runs both in a Web server environment (the session is available, and data is stored there) and outside of a Web server environment (no session is available, such as when you run your unit tests, and the data is stored in memory).

To use it, just declare a public field of StateValue<T> type and the Object Builder injects the object:

public StateValue<MyType> MyStoredValue;

To access it, just use the Value property:

MyStoredValue.Value = new MyType();

This works fine when running the application in the web server. When unit testing however, you’ll notice that the field remains null, because the object builder used for the MockCompositionContainer lacks the strategy that deals with the StateValue<T> fields. Unfortunately, the Reference Implementation that comes with WCSF doesn’t make use of these type of fields so there is no quick example on how to deal with them in tests. You can use the tests covering the builder strategies from the CompositeWeb application block tests, or you can use the following quick reference and save yourself the digging .

The StateValue<T> fields are injected by the SessionStateBindingStrategy. This in turn uses the ISessionStateLocatorService service to obtain an IHttpSessionState object that will act as a repository.

So the first step is to implement a MockHttpSessionState class:

public class MockHttpSessionState : IHttpSessionState
{
public Hashtable Values = new Hashtable();
public object this[string name]
{
get
{
return Values[name];
}
set
{
Values[name] = value;
}
}
// other IHttpSessionState members
}

We can now write a MockSessionStateLocatorService:

public class MockSessionStateLocatorService : ISessionStateLocatorService
{
public MockHttpSessionState SessionState = new MockHttpSessionState();
public System.Web.SessionState.IHttpSessionState GetSessionState()
{
return SessionState;
}
}

The MockCompositionContainer initializes the builder with our mock service and adds the SessionStateBindingStrategy strategy:

class MockCompositionContainer : CompositionContainer
{
public WCSFBuilder CreatedBuilder;
public MockCompositionContainer()
{
InitializeRootContainer(CreateBuilder());
this.Services.AddNew<MockSessionStateLocatorService, ISessionStateLocatorService>();
CreatedBuilder.Strategies.AddNew<SessionStateBindingStrategy>(BuilderStage.Initialization);
}
private WCSFBuilder CreateBuilder()
{
WCSFBuilder builder = new WCSFBuilder();
CreatedBuilder = builder;
builder.Policies.SetDefault<ISingletonPolicy>(new SingletonPolicy(true));
return builder;
}
}

Now the StateValue<T> field gets injected:

[Test]
public void ProvidesAnnouncementToAdd()
{
MockCompositionContainer rootContainer = new MockCompositionContainer();
CompositionContainer moduleContainer = rootContainer.Containers.AddNew<CompositionContainer>();
MyPresenter presenter = moduleContainer.BuildNewItem(typeof(MyPresenter)) as MyPresenter;

Assert.IsNotNull(presenter.MyStateField);
}

What do you need from a MockRepository?

· To know if certain methods have been called.

· To know what parameters were passed to those methods.

· To know what (fake) results were returned.

The base Repository class that the Data Access Guidance Package helps you create has 6 types of methods: SearchOne, SearchMany, SearchAll, Insert, Update and Delete. The derived Repository classes use these to accomplish various tasks (SearchById, SearchByIDParent, etc). For the tests, we’ll use the same model: a base MockRepository class that will be inherited by the actual MockRepositories. In order to be able to use them instead of the real ones, we’ll extract the interfaces from the real repositories, have the MockRepositories implement them, and have the business actions work with these interfaces instead.

The base MockRepository class manages an internal list to simulate a repository:

public class MockRepository<TDomainObject>
{
private List<TDomainObject> _internalList;
public List<TDomainObject> InternalList
{
get
{
return _internalList;
}
set { _internalList = value; }
}
public MockRepository()
{
InternalList = new List<TDomainObject>();
}
public int CCAdd;
public TDomainObject LastAdded = default(TDomainObject);
public virtual void Add(TDomainObject toAdd)
{
CCAdd++;
InternalList.Add(toAdd);
LastAdded = toAdd;
}
public int CCRemove;
public TDomainObject LastRemoved = default(TDomainObject);
public virtual void Remove(TDomainObject toRemove)
{
CCRemove++;
InternalList.Remove(toRemove);
LastRemoved = toRemove;
}
public virtual void Remove(Predicate<TDomainObject> match)
{
CCRemove++;
LastRemoved = InternalList.Find(match);
InternalList.Remove(LastRemoved);
}
public int CCSearchOne;
public TDomainObject LastSearchOne = default(TDomainObject);
public virtual TDomainObject SearchOne(Predicate<TDomainObject> match)
{
CCSearchOne++;
LastSearchOne = InternalList.Find(match);
return LastSearchOne;
}
public int CCSave;
public TDomainObject LastSaveOriginal = default(TDomainObject);
public TDomainObject LastSaveNew = default(TDomainObject);
public virtual void Save(TDomainObject toSave, Predicate<TDomainObject> match)
{
CCSave++;
LastSaveOriginal = InternalList.Find(match);
if (LastSaveOriginal.Equals(default(TDomainObject)))
throw new InvalidOperationException(“The object to be saved could not be found.”);
InternalList[InternalList.IndexOf(LastSaveOriginal)] = toSave;
LastSaveNew = toSave;
}
public int CCSearchMany;
public List<TDomainObject> LastSearchMany = null;
public virtual List<TDomainObject> SearchMany(Predicate<TDomainObject> match)
{
CCSearchMany++;
LastSearchMany = InternalList.FindAll(match);
return LastSearchMany;
}
public int CCSearchAll;
public virtual List<TDomainObject> SearchAll()
{
CCSearchAll++;
return InternalList;
}
}

The derived MockRepositories can implement the methods from the real repository’s interface:

public Question GetQuestionByID(Guid iD)
{
return base.SearchOne(delegate(Question target) { return target.ID == iD; });
}

If necessary, they can add other “flag fields” to be used in tests.

In order to use them in tests, just pass them to the business action instead of the real ones and validate the operation using the Call Count fields (CCMethodName) and/or the Last____ fields for parameters and return values.

MyAction action = new MyAction();
MockQuestionRepository questionRep = new MockQuestionRepository();
MockResultRepository resultRep = new MockResultRepository();
action.QuestionRepository = questionRep;

action.ResultRepository = resultRep;

Result result = action.Execute();

Assert.IsNotNull(result);

Assert.AreEqual(resultRep.LastSearchOne, result);

Assert.AreEqual(1, questionRep.CCAdd);

The Composite UI Application Block (CAB) used in the Smart Client Software Factory (SCSF) allows you to specify which modules will be loaded using an XML file or a web service. The problem is that all the modules you specify get loaded into the root WorkItem. If you have a services module, for example, that is used only by one WorkItem, you have to choose between loading it in the root WorkItem and explicitly loading it in the “AddServices” method of your WorkItemController.

The first option can generate EventBroker problems – all events published by the service will be visible to all WorkItems and vice versa, so you might get some “surprise” event calls.

In the second option you get a tight coupling between the module and its services (not always a real problem, but if you have the service in a separate assembly it could be because you are trying to isolate change between them).

The solution we want is to use the same mechanism as the root WorkItem and load the modules defined in an XML file. One way to do this is to create a service that will be available to child WorkItems.

Add the service interface to the Infrastructure.Inteface project:

public interface IModulesFromFileLoaderService

{

void LoadModules(WorkItem workItem, string catalogFilePath);

}

Then add the service implementation to the Interface.Library project:

public class ModulesFromFileLoaderService : IModulesFromFileLoaderService

{

private IModuleLoaderService _moduleLoaderService;

public ModulesFromFileLoaderService([ServiceDependency] IModuleLoaderService moduleLoaderService)

{

_moduleLoaderService = moduleLoaderService;

}

#region IModulesFromFileLoaderService Members

public void LoadModules(WorkItem workItem, string catalogFilePath)

{

XmlStreamDependentModuleEnumerator modEnumerator = new XmlStreamDependentModuleEnumerator();

ProfileCatalogModuleInfoStore infoStore = new ProfileCatalogModuleInfoStore();

infoStore.CatalogFilePath = catalogFilePath;

modEnumerator.ModuleInfoStore = infoStore;

if (modEnumerator != null)

_moduleLoaderService.Load(workItem, modEnumerator.EnumerateModules());

}

#endregion

}

Register the service:

public abstract class SmartClientApplication<TWorkItem, TShell> : Microsoft.Practices.CompositeUI.WPF.WPFFormShellApplication<TWorkItem, TShell>

where TWorkItem : WorkItem, new()

where TShell : Form

{

protected override void AddServices()

{

base.AddServices();

RootWorkItem.Services.AddNew<ProfileCatalogModuleInfoStore, IModuleInfoStore>();

// …

RootWorkItem.Services.AddNew<ModulesFromFileLoaderService, IModulesFromFileLoaderService>();

}

}

And use it in your module initialization:

WorkItem.Services.Get<IModulesFromFileLoaderService>().LoadModules(WorkItem, “ModuleProfileCatalog.xml”);

Another way to implement LoadModules (more details here) is to use FileCatalogModuleEnumerator from Microsoft.Practices.CompositeUI.Services namespace – its simpler, but is works only with V1 schema files (no sections and dependencies).

public void LoadModules(WorkItem workItem, string catalogFilePath)

{

FileCatalogModuleEnumerator modEnumerator = new FileCatalogModuleEnumerator(catalogFilePath);

if (modEnumerator != null)

_moduleLoaderService.Load(workItem, modEnumerator.EnumerateModules());

}

Something similar can be applied to the validation part. Let’s take an example of a service implementation with WCF Service Factory. Normally you receive a request containing Data Contract objects, you translate those into Business Entities and pass them to a Business Action. This may return a result also expressed as Business Entities that the service implementation must translate into Data Contract objects and forward them to the client.

Luckily, you have a recipe for creating entity translators. But if you want to test the service implementation thoroughly you have to make sure that every property gets properly translated and forwarded from Data Contracts to Business Entities and back. This means lots of “Assert.AreEqual(source.MyProperty, destination.MyProperty)”. More, if you add or remove properties you have to remember to add them to the asserts list, or they will not be tested.

One way to do this automatically (at least for the value-type properties) is to compare the properties that have the same name and type in both objects – taking advantage of the fact that most of the time they are identical. The following method accomplishes this for non-array value or string properties. It can be extended for arrays and indexer properties or even to drill down into reference types, but i find it difficult to follow what exactly gets tested or not. It can also be used for objects of the same type as a quick property-by-property equality check (or you can use it inside an overridden Equals(), but you have to remove the “obj1.Equals(obj2)” from the first if).

public static void EqualByPropertyNames(object obj1, object obj2, params string[] excludeProperties)

{

if (obj1 == obj2 || obj1.Equals(obj2))

return;

Assert.IsNotNull(obj1);

Assert.IsNotNull(obj2);

Type obj1Type = obj1.GetType();

Type obj2Type = obj2.GetType();

PropertyInfo[] properties1 = obj1Type.GetProperties();

List<string> excludedList = new List<string>(excludeProperties);

List<PropertyInfo> properties2 = new List<PropertyInfo>(obj2Type.GetProperties());

foreach (PropertyInfo prop in properties1)

{

if (prop.CanRead &&

(prop.PropertyType.IsValueType || prop.PropertyType == typeof(System.String))

&& !excludedList.Contains(prop.Name)

&& prop.GetIndexParameters().Length == 0)

{

PropertyInfo prop2 = properties2.Find(delegate(PropertyInfo target)

{ return target.Name == prop.Name && target.PropertyType == prop.PropertyType; });

if (prop2 != null)

Assert.AreEqual(prop.GetValue(obj1, null), prop2.GetValue(obj2, null), “Mismatch in objects {1} and {2} – property {0}.”, prop.Name, obj1Type, obj2Type);

}

}

}

The code might look like this:

      [Test]

      public void DoSomethingWorksFine()

      {

            MyObject obj = new MyObject();

            obj.Text = “test text”;

            obj.ID = Guid.NewGuid();

            obj.Date = DateTime.Now;

            // etc.

            testedObject.DoSomething(obj);

            // asserts

      }

Although normally one or two initialized properties are enough, I consider it a good practice to check that all the fields pass well through the test (especially when you’re testing database repositories or web service calls). The problem is that if you use the default values you won’t know if the test passed just because the result has the same initial values.

My solution is a handy utility class that fills the objects properties with random data:

      public static class TestObjectCreator

      {

            static Random rand = new Random();

             public static void FillTestObject(object obj, params string[] excludeProperties)

            {

                  Type objType = obj.GetType();

                  PropertyInfo[] properties = objType.GetProperties();

                  List<string> excludedList = new List<string>(excludeProperties);

                  foreach (PropertyInfo prop in properties)

                  {

                        Object val = GetTestPropertyValue(prop);

                        if (prop.CanWrite && val != null && !excludedList.Contains(prop.Name))

                        {

                              prop.SetValue(obj, val, null);

                        }

                  }

            }

             public static T CreateAndFillTestObject<T>(params string[] excludeProperties) where T: new()

            {

                  T obj = new T();

                  FillTestObject(obj, excludeProperties);

                  return obj;

            }

            private static object GetTestPropertyValue(PropertyInfo propInfo)

            {

                  if (propInfo.PropertyType == typeof(System.Int32))

                        return rand.Next(999999);

                  if (propInfo.PropertyType == typeof(System.String))

                        return string.Format(“{0} – {1}”, propInfo.Name, rand.Next(999999));

                  if (propInfo.PropertyType == typeof(System.DateTime))

                        return DateTime.Now.AddDays(rand.Next(200) – 100);

                  if (propInfo.PropertyType == typeof(System.TimeSpan))

                        return TimeSpan.FromMinutes(rand.Next(999999));

                  if (propInfo.PropertyType == typeof(System.Guid))

                        return Guid.NewGuid(); 

                  return null;

            }

      }

It basically has methods to fill an existing object or to create and fill a new one, optionally skipping some properties if it’s necessary. And to use it:

      [Test]

      public void DoSomethingWorksFine()

      {

            MyObject obj = TestObjectCreator.CreateAndFillTestObject<MyObject>();

            testedObject.DoSomething(obj);

            // asserts

      }