Unit Testing In Enterprise Library

Tuesday, February 15, 2005

Let me start by pointing to Tom Hollander, who is looking for feedback and input to build the next version of Enterprise Library.

I now return you to my irregularly scheduled ramblings...

Unit testing is here to stay. The only questions about unit testing revolve around the details. Do we test non-public types and methods? Do we use mock objects? I’m always interested in seeing real unit testing code from other projects to understand what decisions others have made. (For an intro to unit testing, see: “Improve the Design and Flexibility of Your Project with Extreme Programming Techniques”).

Enterprise Library uses the NUnit testing framework. It will be interesting to see how easily this will port to the VS 2005 unit testing framework (or even if the tests are ported to 2005, considering the unit testing framework may only be included with the Team System version of Visual Studio 2005). I know I’m chiming in late, but I hope we see unit testing in all versions of Visual Studio.

Enterprise Library includes unit tests in the same assembly as the classes being tested. Tests are surrounded with an #ifdef, presumably to keep them out of production builds and also to allow the library to compile on systems without NUnit.

The unit tests do access members with internal scope.

Unit testing code in EntLib is not in short supply. Here is a snippet from ConnectionStringFixture.cs:

   44 [Test]
   45 public void CanGetCredentialsFromRealSqlDataClass()
   46 {
   47    string initialConnectionString = 
   48       String.Format("server=localhost; database=JoeRandom; uid={0}; pwd={1}; ;", 
   49          userName, password);
   50    this.connectionString = new ConnectionString(initialConnectionString, userIdTokens, passwordTokens);
   51    Assert.AreEqual(userName, this.connectionString.UserName);
   52    Assert.AreEqual(password, this.connectionString.Password);
   53 }

The ConnectionStringFixture class has 10 tests in all:

InvalidOperationExceptionThrownWhenConnectionStringIsNull()
EmptyCredentialsReturnedForEmptyConnectionString()
CanGetCredentialsFromRealSqlDataClass()
CreateNewConnectionStringTest()
CreateNewConnectionStringTest()
CanAddCredentialsToConnectionStringThatDoesNotHaveThem()
CanSetUserIdAndPasswordInConnectionStringThatAlreadyHasOne()
RemovingCredentialsFromConnectionStringWithoutThemIsOk()
WillRemoveCredentialsFromConnectionString()
NullTests()

The overall style and naming conventions stick to accepted practices for writing unit tests. One issue up for debate is the testing of internal methods. I like the approach. Internal members are good candidates for testing since they often form the surface area of an API one layer beneath the public façade. After a short conversation with Rocky this week - I realize there is at least one person who doesn’t agree.

What do you think? (Regarding ‘what to test that is’ – I know some of you think about a lot of things).

Coming soon: Mock classes - and why they make me uncomfortable.

All My Pluralsight Courses

OdeToCode by K. Scott Allen