I am currently working on an article for Microsoft's MSDN Magazine that describes how to write lightweight Web application UI test automation using the jQuery library. One of the technical reviewers of my article asked me about the pros and cons of using the jQuery approach compared with using the Selenium test framework and the Watir test framework. A second reviewer asked about the difference between using jQuery and using plain vanilla JavaScript. Additionally, a third reviewer pointed out that there is a new .NET based test framework named ASP.NET QA.

 

OK, let's start with jQuery vs. plain JavaScript for Web app automation. The two approaches are very similar. Using the jQuery library has the advantages of a consistent selector and manipulator syntax to get references to controls, such as submit buttons, and syntax to set and examine control values. Additionally, jQuery is mostly browser agnostic so you don't have to worry about whether code such as document.all["TextBox1"] will work with Firefox or not. One disadvantage of jQuery vs. plain JavaScript is that jQuery represents an external dependency to some extent. Now for jQuery test automation vs. using Selenium. Selenium is an excellent tool, but in my opinion a non-technical disadvantage of using Selenium is that time spent learning the Selenium framework does not help you directly with improving your developer skills. When using jQuery to write test automation you are learning skills which can be used not only for testing but also for Web development. One advantage of Selenium is that it is a big framework and has a lot of functionality at one higher level of abstraction than jQuery, so writing test automation with Selenium can be quicker than with jQuery (after you get over the initial Selenium learning curve). I am personally not a fan of Watir mostly because I just don't like coding in Ruby nearly as much as I like coding with JavaScript. So for me jQuery has the advantage of using JavaScript which directly maps to improved development skills. An advantage of Watir compared to jQuery is that the Watir framework is quite well known so there is good documentation and support. Although I'm not positive, I believe that Watir works only with Internet Explorer, which if true, is a disadvantage compared to using jQuery. Now there is also Watin, which does not have the Ruby language disadvantage, but using C# or some other .NET compliant language does not directly map to improved Web development skills either. One of the reviewers of my jQuery article pointed out that there is a new "ASP.NET QA" framework available on CodePlex, Microsoft's open source site. I haven't had a chance to examine ASP.NET QA closely but it looks pretty nice.

In some software test automation scenarios you may want the test harness to programmatically send test results via e-mail in addition to, or instead of, saving results to a file or database. In a .NET environment, this is pretty easy to do. The first step is to configure the test host machine, which is running the test automation, as an SMTP server so the host can send mail. On Windows XP, if you have configured IIS, in most cases SMTP will also be enabled, but not configured. In Computer Management, under IIS, open the SMTP Virtual Server Properties dialog. On the General tab, enter the IP address of the host machine. Port 25 will be the default. Then on the Access tab, Connection section, add the IP address of the test host machine. Now your test host can send mail. You can use the older System.Web.Mail namespace, or the newer System.Net.Mail namespace. C# code to send mail this looks like:

 

using System.Net.Mail;

try
{
  SmtpClient c = new SmtpClient("10.20.30.40", 25); // host IP, port
  MailAddress mFrom = new MailAddress("results@testHost");
  MailAddress mTo = new MailAddress("somebody@somewhere.com");
  MailMessage m = new MailMessage(mFrom, mTo);
  m.Subject = "Test Results at" + System.DateTime.Now;
  string mBody = "Number Pass = 120\nNumber Fail = 0";
  m.Body = mBody;
  c.Send(m);
}

 

If your test host machine is not running under a .NET environment, you can use the old CDONTS or the newer CDOSYS ActiveX libraries.

The new F# programming language is interesting. One possible reason for learning a new programming language is an effect that is closely related to something called the Sapir-Whorf hypothesis (SWH). In over-simplified terms, the SWH says that speakers of different languages (English, Japanese, etc.) think differently because of differences in languages. So an extension of this idea is that programmers and testers who use C# may program and test differently than those who use LISP, and so the more programming languages you know, the more programming patterns you have available. That aside, in a recent Introduction to F# Programming class I taught, most students (and I) said they were in the class out of technical curiosity and for intellectual entertainment. One of the examples I put together for the class has a nice set of thematic F# syntax and paradigms. See the image below for a sample run.

 

 1 #light
 2 open System
 3 printfn "\nBegin F# deck of cards demo"
 4 let deck =
 5   [| for suit in ["Clubs"; "Diamonds"; "Hearts"; "Spades" ] do
 6     for rank in [1..13] do
 7     yield (rank,suit) |]
 8
 9 printfn "\nThe unshuffled deck is %A \n" deck   
10 let ro = new Random(0) 
11 let shuffle (a : (int*string) array) =
12   let len = a.Length
13   for i in 0..len-1 do
14     let r = ro.Next(i, len-1)
15     let tmp = a.[r]
16     a.[r] <- a.[i]
17     a.[i] <- tmp
18 
19 deck |> shuffle
20
21 let printDeck (d : (int*string) array) =
22   let n = d.Length
23   for i in 0..n-1 do
24     if i > 10 && i < 49 then printf "."
25     elif i = 49 then printf "\n"
26     else
27       printf "card[%d] = " i
28       if i < 10 then printf " "
29       let (rank,suit) = d.[i]
30       if rank < 10 then printf " "
31       printfn "%d of %s" rank suit
32   
33 printfn "\nThe shuffled deck is: "
34 deck |> printDeck
35
36 printfn "\nEnd deck of cards demo"
37 System.Console.ReadLine() |> ignore

 

Lines 4-7 construct a mutable array of size 52, where each cell holds a tuple composed of an int (a card value from 1-13) and a string ("Clubs", etc.) Line 9 uses the %A format specifier to instruct the F# compiler to use its own judgment on how to print the array of card tuples. Lines 11-17 define a function which uses the Fisher-Yates shuffle algorithm to shuffle an array in place. Line 19 pipes the deck to the shuffle function. Lines 21-31 define a custom print function. Line 37 points out that F# is a .NET language and can access the .NET Framework. One thing I found interesting is that, more than any language I can think of, F# has many different ways to perform programming tasks. For example, Lines 29-31:

 

let (rank,suit) = d.[i]
if rank < 10 then printf " "
printfn "%d of %s" rank suit

 

can also be coded as:

 

match d.[i] with
| (rank,suit) ->
  if rank < 10 then printf " "
  printfn "%A of %A" rank suit

 

which is more F#-ish. Anyway, F# is really interesting in many ways.

 

Based on my personal experience, I have observed a large disconnect between the fields of software testing research (the kind typically done at universities) and software testing practice (as performed by companies which actually produce software). The two groups involved -- university researchers and software test engineers -- seem particularly unaware of each other's work. Well this isn't very surprising I suppose, but I'm thinking that there should be some easy way for software testing researchers and practitioners to be learn about each other's worlds. I speak at quite a few academic conferences and many of the research papers on software testing presented there are ridiculously out of touch with present or future reality, but on the other hand there are some papers that have really interesting and potentially really useful ideas. Now in theory at least, every academic conference looks for papers from practitioners -- the "call for papers" almost always says something like, "The aim of the XYZ Conference is to bring together researchers and practitioners in an effort to highlight the state-of-the-art and to present and discuss ideas and experiences to explore new directions for blah, blah, blah." However, papers from practitioners are almost never accepted at academic conferences. One reason is that writing a good academic paper is really quite difficult. Academic researchers can spend years to produce a single paper, and you have to know the "secret ingredients" of an IEEE research paper content and format. Anyway, I'm rambling today; let me cut to the chase. I am the chair of the software testing track of the ITNG 2010 Conference and I'd love to see papers from practitioners, and I do not discriminate against authors who don't have a Ph.D. degree. If you have an idea for a paper about software testing I can help you get the idea into a formal IEEE format. See http://www.vteonline.com/ITNG2010/ for a description of the conference, and see http://www.vteOnline.com/ITNG2010/Guidelines/guidelines.html for some tips about writing a research paper.