One of the biggest secrets of Enterprise Library is that we shipped it with 1800 NUnit unit tests. These tests reflect our best efforts to write this code in an agile, Test-Driven style. Sometimes we were more successful than others, but the fact remains, we did a damn good job of writing tests for our code.
What do the unit tests do for me?
As a developer, these unit tests are a great resource. First and foremost, they tell you whether or not Enterprise Library is working. These tests should run all the time at 100% success (give or take a few that are timing dependent — our fault…). They also serve as excellent examples of how Enterprise Library works. Have a question about how to pass parameters to a stored procedure using Oracle? Well, my friend, there is a unit test that we wrote that does that exact thing, and you can look at it and see exactly how it works!
The tricky part is that these tests are undocumented, and the process of getting them to run is undocumented. So, here is my best shot at telling you how to get our tests to run. If I’ve missed anything, or something is unclear, please let me know, and I’ll update this page.
The instructions:
- Install Visual Studio .Net 2003
- Install either MSDE or SqlServer (Oracle and DB2 are optional)
- Install MSMQ
- Install .Net framework 1.1
- Install NUnit 2.1.4
- Download and install Enterprise Library. You don’t need to compile it at this point, as we’ll do it manually shortly.
- Start Visual Studio and open EnterpriseLibrary.sln
- Change build target from Debug to DebugUnitTests
- Rebuild solution
- Open a visual studio command prompt and navigate to c:\Program Files\Microsoft Enterprise Library\src\Common\Instrumentation\Scripts. Run this command without the quotes: “InstallInstrumentation.cmd DebugTests”
- Run the following scripts from the given directories:
- src\Caching\Scripts – CreateCachingDb.cmd
- src\Logging\Sinks\Database\Scripts – CreateLoggingDatabase.cmd
- src\Security\Database\Scripts — CreateSecurityDatabase.cmd
- Open “C:\program files\nunit-2.1\bin\nunit-gui.exe”
- File->Open and navigate to the assembly you want to test. Quick word of warning — Many of our unit tests use custom configuration files to provide the test setup that they need. You can only run the tests for an assembly in that assembly’s “home” directory. For example, you can only open and test Microsoft.Practices.EnterpriseLibrary.Caching.Database.dll in the src\Caching\Database\bin\DebugTests directory, because that is where its configuration lives.
NOTES:
- Data — 56 tests will fail if you do not have Oracle installed. If you do happen to have oracle installed, you’ll need to manually open the Data\Tests\TestConfigurationContext.cs file and change your oracle connection settings.
- Logging — EmailSinkFixture.LogMessageToEmail will fail, since you do not have access to our internal mail server. You can fix this by changing Logging\Tests\EnterpriseLibrary.LoggingDistributor.config on line 22 to reference different smtpServers and to and from addresses.
- Security.ActiveDirectory — Tests will fail because you cannot access our Active Directory server. There are instructions about how to set up ADAM in Security.ActiveDirectory.Configuration.ADAM Setup. You’ll also need to change line 53 in Security.ActiveDirectory.Tests.TestConfigurationContext to reflect your ADAM setup.
- EnterpriseLibrary — It is normal for several of the tests to occasionally fail. There are a few unit tests that are timing-dependent, especially in Caching and Configuration. These tests are testing whether or not something happens during a particular time interval, and sometimes the system delays the actions too long and those tests fail. If you rerun the test, it should work the next time. Additionally, our tests write to the event log, which occasionally fills up. If you begin to see a number of tests failing, check that your application event log is not full.