I was teaching an introduction to ASP.NET class last week and a very confusing idea for beginners is Web application creation. If you create a Web app using Visual Studio, all kinds of magic happens behind the scenes which makes it difficult if you want to know how to create a Web app from scratch. In this blog entry I'll try to explain. If you use Visual Studio 2005 on Windows Server 2003 (unfortunately the details are somewhat different on Windows XP and I won't cover XP here) to create a new Web Application, you can go File | New | Web Site. Right away this is confusing. You are not really creating a Web site, you are creating a Web application on your existing Web site. This is just plain bad wording on the part of VS. In the Location field, suppose you specify http://localhost /SomePlace  /AppCreatedByVS and then click OK as shown in the first image below. To see the result, you can go to the IIS Manager (right-click on My Computer | Manage | Services and Applications). As shown in the second image below, you get an ordinary directory named SomePlace which contains a special directory named AppCreatedByVS that has a gear icon, which means it holds an ASP.NET application. Notice that Visual Studio automatically creates two files: Default.apx which holds the HTML and display code, and a separate Default.aspx.cs which holds the C# logic code. Now if you examine your file structure using Windows Explorer as shown in the third image, you'll see that Visual Studio magic actually created a physical organization of C:\Inetpub\ wwwroot\ SomePlace\ AppCreatedByVS that maps to your virtual structure. (The screenshots were taken on a machine where the D: drive is the system drive rather than the C: drive.) The Web application is accessed in Internet Explorer by navigating to http://localhost/ SomePlace/ AppCreatedByVS/ Default.aspx (where you can leave off the "Default.aspx" if you wish).

 

OK, that's all just fine, but what if you want to create an ASP.NET Web application without using Visual Studio? Let's see how to create a Web app from scratch that you'd access by navigating to http://localhost/ OtherPlace/ AppCreatedByIIS/ Default.aspx. First, you must manually set up a directory structure except for the final directory. So, in Windows Explorer you must create a directory named OtherPlace at C:\Inetpub\ wwwroot\. (In advanced scenarios you can place the directory somewhere else.) See the fourth image below. Now in the IIS Manager, select directory OtherPlace and then right-click select New | Virtual Directory. (Important side note: if you have the Default Web Site entry selected then you'll get an option to create a New Web Site. This is not what you want in spite of the fact that Visual Studio incorrectly calls a new Web application a new Web Site.) The wizard will ask you for the Alias; here you enter the name for the last-level directory, which is also the name of the Web application, which in this case would be AppCreatedByIIS. Next the wizard asks you for the physical directory which will hold your files. This part is very tricky -- you use the Browse dialog to go to directory OtherPlace (in other words to one directory higher than the ultimate application directory), then click on the Make New Folder button, which makes a directory New Folder, which you can then right-click on and select Rename, and then rename to AppCreatedByIIS (in other words you give the directory the same name as the Virtual Directory alias), and then select this new directory. See the fifth image below. Note: this ballet is the only sequence that gives you the exact same result as Visual Studio, but there are many different orders of steps you can use that will give you similar, but not exactly the same, results. Next you'll see Permissions. You must check Run Scripts as shown in the sixth image below. After finishing up, the seventh image shows you the result as you'd see in the IIS Manager. Notice there are no files in directory AppCreatedByIIS. Here is where you could create a single Default.aspx file which contains both HTML display and C# logic code (or separate files for display and logic). However, there is yet another detail. The last image below shows you that when you create a Web application from scratch, the Application Pool setting is "DefaultAppPool" rather than "ASP.NET V2.0" as it is when you create a Web app using Visual Studio. Additionally, you should check the ASP.NET tab (in the upper right hand corner) to make sure you are set to ASP.NET 2.0 version.

I oversee a technical training program for software engineers working at Microsoft. The majority of these engineers work in software testing roles. In order to determine which training classes to schedule, every now and then I send out a survey to Microsoft test managers asking them which test technologies, programming languages, skills, and techniques they expect all testers to know. Approximately 120 test managers responded to my most recent survey. The results were very clear: there are four key automation techniques that Microsoft test managers expect all testers to know, and they are:

 

Now not every product team at Microsoft necessarily uses all these techniques, and there are many other required testing techniques, however, all testers should absolutely know how to write these four types of test automation. There are of course many ways to perform each of these types of test automation. For example, Web application UI test automation can be written using a script-based DOM approach (see my article at http://msdn.microsoft.com/msdnmag/issues/07/02/TestRun/default.aspx), or you can use low-level calls into the mshtml.dll and shdocvw.dll libraries (see my article at http://msdn.microsoft.com/msdnmag/issues/05/10/TestRun/), or you can use a hybrid approach with Windows PowerShell (I have an MSDN Magazine written but not yet published). The test managers' comments attached to the surveys were also quite interesting, and in some cases unsettling. Many Microsoft test managers mentioned something to the effect that at Microsoft there is a very disturbing trend where even software testers with lofty titles such as "Senior Software Design Engineer in Test" and "Test Architect" do not have the ability to actually write test automation code anymore. The comments suggested that these high-end employees see actual testing as beneath them and that "architecting" a test system is more important than actually testing. Well, test system architecture is certainly important but I definitely would not want to work in a group where senior test engineers are not up to speed with the latest test automation skills. My point is that I am essentially a manager but I spend a lot of time upgrading my actual technical skills so that I can manage better. When senior testers at Microsoft, or any other company, lag far behind software developers in their ability to write code, the credibility of software testing as a discipline suffers. And rightfully so. If you are in the field of software testing you are kidding yourself if you believe that you will ever reach a point where you do not need to learn how to write test automation using new techniques.

In my last blog entry I described what the new Microsoft UI Automation (MUIA) library is. Now let me walk you through a very simple Hello World example for Microsoft UI Automation. Check out the image below to see where I'm headed. The screenshot shows I created a console application test harness which uses MUIA to test a simple .NET form-based application. Prepare the example by installing the .NET Framework version 3.0 on your machine if necessary. Begin by creating a simple .NET form-based application named HelloWorld at a directory named C:\MUIADemo which simply displays "Hello world" in textBox1 when button1 is clicked. Now create a new C# console application Project named TestAuto at C:\MUIADemo. In TestAuto, locate and add Project References to the UIAutomationClient.dll and UIAutomationTypes.dll libraries. Now add a "using System.Windows.Automation" statement to your code. Then add using statements to System.Diagnostics and System.Threading. Now type this code into the Main() method of your test harness:

Console.WriteLine("\nMUIA test automation demo \n");

Console.WriteLine("Launching app, clicking button1 now");

Process p =
  Process.Start("..\\..\\..\\HelloWorld\\bin\\Debug\\HelloWorld.exe");
Thread.Sleep(5000);
AutomationElement aeForm =
  AutomationElement.FromHandle(p.MainWindowHandle);
AutomationElement aeButton = aeForm.FindFirst(TreeScope.Children,
  new PropertyCondition(AutomationElement.NameProperty, "button1"));
AutomationElement aeTextBox = aeForm.FindFirst(TreeScope.Children,
  new PropertyCondition(AutomationElement.ControlTypeProperty,
    ControlType.Edit));
InvokePattern ipClickButton1 =
  (InvokePattern)aeButton.GetCurrentPattern(InvokePattern.Pattern);
ipClickButton1.Invoke();
Console.WriteLine("\n . . .check value in textBox1 and
  print pass/fail here");
Console.ReadLine();

 

Build and run your harness. Let me point out that this is just a simple example to get you started with Microsoft UI Automation. The code above has many problems and isn't usable in a production environment. I just finished writing up a thorough introduction to Microsoft UI Automation for my monthly Test Run column which appears in MSDN Magazine and I'm hoping that the article will be printed sooner rather than later.

I've been investigating the new Microsoft UI Automation (MUIA) library over the past few months. MUIA is a large code library that helps you write UI test automation for Win32, .NET, and WPF applications. I've discovered there is quite a bit of good high-level documentation for MUIA available on the Internet, but currently there is almost no good "how-to", "nuts-and-bolts" information. I hope to remedy that with a series of blog entries and MSDN Magazine articles. The term "Microsoft UI Automation" is a bit fuzzy. More specifically the actual functionality of much of MUIA is contained in the System.Windows.Automation namespace (and others) of the .NET Framework. The functionality of this namespace is in turn contained in four DLL libraries, including a UIAutomationClient.dll which ships as part of the .NET 3.0 Framework. You can think of MUIA as a successor to the old Microsoft Active Accessibility (MSAA) library. MSAA was originally intended just for accessibility but was found to be useful for test automation. Microsoft UI Automation was designed from the outset for both accessibility and test automation. I believe that MUIA will quickly become the most widely-used method for Windows application UI test automation. The Microsoft UI Automation library is free, and because it ships with .NET 3.0 the library is a de facto standard.

I've run into an interesting technical roadblock. A core test automation technique is automated UI testing for Windows form-based applications, where the test automation manipulates a "regular" program through the program's user interface. There are several ways to do this but my preferred way is to make Win32 API function calls (such as to the SendMessage() function) using C# with the P/Invoke mechanism. Test automation scenarios using this technique often contain code which accesses the Main Menu (File, Edit, View, etc.) of application under test. There is a special set of Win32 API functions which manipulate an application's Menu: GetMenu(), GetSubMenu(), and GetMenuItemID(). So far, so good, for test automation to manipulate a MainMenu on most Windows form-based applications. But the .NET Framework versions 2.0 and 3.0 have a new way for application developers to create a Menu. The new control is called the menuStrip control and you can think of it is an optional upgrade to the older MainMenu control. The menuStrip control looks nicer, has additional features, and is more consistent with other control models than the older MainMenu control. However, in some preliminary test automation experiments on applications which use the new menuStrip control, I have been completely unable to access and manipulate the menuStrip control using existing Win32 API functions, or find any new Win32 API functions which work with the menuStrip control. Perhaps it's just not possible to automate a menuStrip using Win32, and I'll have to rely on built-in .NET methods and properties of the menuStrip control. I'll write up the solution to this technical roadblock when I figure it out.

By far the biggest change in the field of software testing over the past couple of years has been the increased use of software test automation (programs which test the system under development). Although you can purchase a commercial test automation framework from companies like Mercury (HP), Segue, Rational (IBM), and many others, a more flexible approach is to write custom test automation code. If you write your own test automation code, you can use a fully-compiled language (typically C or C++), an intermediate-compiled language (Java, C#, VB.NET), classic Visual Basic (which I feel is a language in its own category), or a scripting language. Scripting languages are often a good choice of a language for test automation in Agile-style environments, and scripting language automation almost always nicely complement larger and more complex test automation environments. The seven main scripting languages I've used for test automation are Perl, JavaScript, VBScript, Python, Ruby, PHP, and PowerShell. I really like all seven of these scripting languages and I think each has strengths and weaknesses. Perl is the grand-daddy of scripting languages and has the advantage of the availability of a huge set of code libraries. JavaScript has the advantages of working very well with Web browser Document Object Models (especially the IE DOM), and with ActiveX / COM objects. VBScript has been around for a long time so you can find tons of example code on the Internet. I see Python as an improved Perl (object oriented capabilities are designed in rather than more or less tacked on). Ruby work very well with Web applications and the RoR framework (Ruby on Rails) in particular. PHP also works very well with Web applications, especially those developed using PHP. And Windows PowerShell is terrific for testing .NET systems because PowerShell can directly call into the .NET Framework. There has been a huge growth of technologies over the past few years and in general it's no longer possible for testers to have a fairly deep knowledge of every scripting language. But the more you know about a range of different scripting languages, the stronger asset you'll be to your project team, and the more career growth opportunities you'll get.