I.M. Testy

I am almost through my first week in my new job here at Microsoft and trying to get my head wrapped around everything. It is really exciting to work on new technologies and in a feature area that helps users stay connected with friends and family in amazing ways. For now, let’s just say that I feel like I am treading water which is not unusual when changing jobs within Microsoft. But, of course, that is a good thing. If I felt like I could’ve easily stepped into this job I would not feel challenged, I would not open my mind to learn new things, and I would likely be bored after a few months. Yes…I am a bit overwhelmed in a very exciting way!

Of course, I am still teaching classes at the University of Washington Extension, and am currently teaching a class in test automation design. A few sessions ago we hit an issue with some canned examples failing to run properly on 64-bit operating systems. This problem appeared for 2 reasons:

• I developed the lab examples 2 years ago before I upgraded my home system to a 64-bit machine and have only ran them in the classroom environment since
• I hard-coded the Program Files folder environment path to C:\Program Files.

Of course, it is a bit embarrassing as an teacher when your samples do not run (it’s even worse when they don’t even build, but that is a different story). In a training situation it is often easier to control the environment to minimize problems and allow learners to (initially) focus on the main topic or skill being presented. But, the downside is that many of us don’t work in ‘controlled’ environments in the real world. And while I am adamantly opposed to hard-coded strings in code, I find that sometimes I ignore my own advice in samples or demo code (and it often comes back to haunt me).

The specific problem was that on a 64-bit operating system the application is installed to the Program Files (x86) folder instead of simply the Program Files folder and the application failed to launch when we attempted to start the process. The solution is actually quite simple in this case because we can actually call the ProgramFiles member of the Environment.SpecialFolder enumeration. For example, a hard-coded path on a default installation

string autPath = @"c:\program files\[autFolder]\[autName.exe]";

failed on a 64-bit system, so a better approach to detect the ‘correct’ program files directory might be

string autDefaultFolderName = "[aut_folder_name]";
string autExecutableName = "[filename.exe]";
string autPath = System.IO.Path.Combine(
  Environment.GetFolderPath(Environment.SpecialFolder.ProgramFiles),
   autDefaultFolderName,
   autExecutableName);

The ProgramFiles member of the Environment.SpecialFolder will return Program File on a 32-bit machine, and Program Files (x86) on a 64-bit machine.Of course, this works fine for the default installation folder, but if for some reason you need to run your automation on installations of an application under test in a non-default directory then you would need to qualify the path in other ways.

Also, this is just one difference between a 32 and 64-bit operating system environment, but there are other situations where we want to detect bit-ness so we can write a single test rather than one test for 32 bit operating system environments and another for 64-bit operating system environments. Fortunately, the .NET 4.0 framework makes it really easy to detect whether a machine is 64-bit or not with the Environment.Is64BitOperatingSystem property. For example, you can control flow for 64 vs 32 bit with a simple decision such as:

if (Environment.Is64BitOperatingSystem)
{
  // TODO 64-bit stuff
}
else
{
  // TODO 32-bit stuff
}

But, if you are running the .NET 3.5 framework or earlier it becomes a bit more complicated to detect 64-bit operating systems. The following method can help determine whether or not your operating system environment is 64-bit

public static bool Is64BitOperatingSystem()
{
  if (!string.Equals(Environment.GetEnvironmentVariable(
    "PROCESSOR_ARCHITECTURE"), "x86", StringComparison.OrdinalIgnoreCase) ||
    !String.IsNullOrEmpty(Environment.GetEnvironmentVariable(
    "PROCESSOR_ARCHITEW6432")))
    {
      return true;
    }

     return false;
}

There are also Win32 API functions we can P-Invoke such as GetSystemInfo,

So, rather than having separate automated tests for 32 and 64 bit operating systems a better test design approach might be to simply detect the bit-ness and auto-magically set variables or redirect the control flow path through your test for the appropriate operating system environment.