Scott Dorman

ephemeral segment

  Home  |   Contact  |   Syndication    |   Login
  603 Posts | 10 Stories | 862 Comments | 51 Trackbacks

News


Post Categories

Image Galleries


Microsoft Store


Creative Commons License



Locations of visitors to this page

Subscribers to this feed

TwitterCounter for @sdorman

View blog authority

Add to Technorati Favorites

Windows Live Alerts

AddThis Social Bookmark Button

LinkedIn profile

Community Credit profile

The Code Project

Follow me on Twitter

Get Free Shots from Snap.com

Community Credit Hall of Fame

Get Feedghost

Xobni outlook add-in for your inbox



Support This Site

Tag Cloud


Article Categories

Archives

Post Categories

Image Galleries

This question is for all of the TDD and unit test folks, so I’m hoping someone comes up with an answer.

I’ve been writing unit tests and analyzing code coverage for one of my libraries for about a week now and I’m starting to see the end, at least for this particular library. However, I’ve run in to a problem trying to ensure as close to 100% code coverage as possible. This exists in several methods in a few different classes, but I’ll take the simplest one for illustration purposes.

I have cod that looks like this:

   1: public static ProcessorArchitecture GetProcessorArchitecture()
   2: {
   3:     SYSTEM_INFO sysInfo = new SYSTEM_INFO();
   4:  
   5:     if (Environment.OSVersion.Version.Major > 5 || (Environment.OSVersion.Version.Major == 5 && Environment.OSVersion.Version.Minor >= 1))
   6:     {
   7:         SafeNativeMethods.GetNativeSystemInfo(out sysInfo);
   8:     }
   9:     else
  10:     {
  11:         SafeNativeMethods.GetSystemInfo(out sysInfo);
  12:     }
  13:  
  14:     ProcessorArchitecture architecture = ProcessorArchitecture.Unknown;
  15:     switch (sysInfo.uProcessorInfo.processorArchitecture.wProcessorArchitecture)
  16:     {
  17:         case Constants.PROCESSOR_ARCHITECTURE_AMD64:
  18:             architecture = ProcessorArchitecture.X64;
  19:             break;
  20:  
  21:         case Constants.PROCESSOR_ARCHITECTURE_IA64:
  22:             architecture = ProcessorArchitecture.Itanium;
  23:             break;
  24:  
  25:         case Constants.PROCESSOR_ARCHITECTURE_INTEL:
  26:             architecture = ProcessorArchitecture.X86;
  27:             break;
  28:     }
  29:  
  30:     return architecture;
  31: }

My unit test for this particular method is relatively simple as well:

   1: [TestMethod]
   2: public void GetProcessorArchitecture()
   3: {
   4:     ProcessorArchitecture expected = ProcessorArchitecture.X86;
   5:     ProcessorArchitecture actual = ExtendedEnvironment.GetProcessorArchitecture();
   6:     Assert.IsTrue(actual == expected);
   7: }

The problem here is that not all of this method is able to covered. Specifically, the else clause and the first two cases in the switch. Short of physically changing hardware or operating systems, how do I actually unit test those conditions? I don’t think creating a mock object will help in this case, as the object I would need to mock is the System.Environment object and then somehow be able to alter the processor architecture field of the SYSTEM_INFO struct that is returned from GetSystemInfo().

I realize this is a somewhat trivial example, but I think it does clearly demonstrate the impossibility of achieving 100% code coverage through unit tests.

DotNetKicks Image
posted on Saturday, January 17, 2009 10:35 PM