[ValidationMethod] Attribute

Just because StructureMap can successfully call a constructor function with configured properties does not mean the object can actually perform work.  The new [ValidationMethod] attribute can be used to provide runtime verification of an environment.  Consider the code below:

[PluginFamily]
public interface IDataStore
{
	void AddUser(string userName);
}

[Pluggable("Default")]
public class DataStore : IDataStore
{
	private readonly string _connectionString;

	public DataStore(string connectionString)
	{
		_connectionString = connectionString;
	}

	public void AddUser( string userName )
	{
		string sql = string.Format("insert into table users (user_name) values ('{0}')", userName);
			
		using (SqlConnection connection = new SqlConnection(_connectionString))
		{
			SqlCommand command = new SqlCommand(sql, connection);
			command.ExecuteNonQuery();
		}
	}

	[ValidationMethod]
	public void TestConnection()
	{
		SqlConnection connection = new SqlConnection(_connectionString);

		try
		{
			connection.Open();
		}
		finally
		{
			connection.Close();
		}
	}
}

	  

StructureMap will be able to create this class with any value for “connectionString” that is a valid string, but DataStore cannot function if the database connection string is incorrect or invalid in someway.  The application cannot function correctly if the database cannot be reached.  However, decorating a method with the [ValidationMethod] attribute instructs StructureMap to call the method after creating an object to perform runtime validation.  During verification in either StructureMapDoctor  or the verification NAnt task, StructureMap will create every configured instance of DataStore and call the TestConnection() method.  If a connection cannot be opened to the configured connection string, an exception will be thrown and StructureMap will report the full exception message and stacktrace.

This mechanism can be used to create an automatic “smoke” test of the development and testing environments.  In any enterprise software development project, a significant loss of productivity is a test environment that is either misconfigured, or a piece of infrastructure like a database server is temporarily powered down.  A tester and I once suffered a full week of frustration troubleshooting a newly developed data exchange.  Later we found out that the integration server we were depending on in testing was being upgraded that week and had been rebooted often while we were testing.  Ignoring the egregious lack of communication, an automatic verification of the testing environment prior to testing would have saved a great deal of time in an already stressful project.