SnapDAL helps you write tests for your code

Here is an example of testing a class named ConfigurableFoo that is connected to a database with SnapDAL. The connections, IDbCommand, readers are not accessible to the test code. Only configuration parameters are available.

	class ConfigurableFoo
	{
		
		string _conn = Configuration.ConnectionString;
		string _provider = Configuration.Provider;
		DirectoryInfo _statementsDir = new DirectoryInfo(Configuration.StatementsDirectory);
		DataFactory _dal;
		public string Company;
		public string ContactTitle;

		public ConfigurableFoo() 
		{
			_dal = new DataFactory(_conn, _provider, true, _statementsDir);
		}
			
		public void Load(string customerid)
		{
			HybridDictionary parms = new HybridDictionary(1);
			parms.Add("customerid", customerid);
			IDataReader rdr = _dal.ExecuteDataReader("query_customer", parms);
			using (rdr)
				if (rdr.Read())
				{
					Company = rdr["CompanyName"].ToString();
					ContactTitle = rdr["ContactTitle"].ToString();
				}
		}
	}

	internal class Configuration
	{
		public static string ConnectionString;
		public static string Provider;
		public static string StatementsDirectory;

	}

What's important here is that the class is responsible for creating it's data access, based on configuration settings. Here is the magic that SnapDAL can do for you as a minimal stub (as opposed to verifieable mock object)

/// 

/// Tests that a class that provides it's own transparent access to data can be stubbed
/// 
	[Test]
	public void ReadFromDataSetStyle()
	{
		Configuration.StatementsDirectory = samplestatements;
		Configuration.Provider = "Mock";
		//setup the test which is configured in config files mock.config and 
		//mockreadertest.config
		MockProvider.TestName = "mockreadertest";

		ConfigurableFoo foo = new ConfigurableFoo();
		foo.Load("ALFKI");
		Assertion.AssertEquals("didn't load company data with mock reader", "test Alfreds Futterkiste", foo.Company);
		Assertion.AssertEquals("didn't load product data with mock client", "test The Boss", foo.ContactTitle);

	}

Viola! Of course, there is more to this story. A IDataReader must have been returned in order for the test to pass, but the code did not supply it! OK, there was a trick. In an earlier pass, using a SqlClient, the test was "Recorded" to an xml file for a test called mockreadertest. The data from that recording is automatically attached to the mock IDbCommand when the caller invokes the query. This happens whether you are working directly with the IDbCommand or you go through the DataFactory.