WatiN 2.0 has just gone to Release cantidate, and is chock full to automated testing goodness, head over to http://watin.sourceforge.net/releasenotes-2-0-20-1089.htm for the full release notes.
At my customer the good old problem of needing to run tests as different users came up again. I have tried to solve this before and came up with parts of the login dialogue handler.
The problem is this: when IE starts it uses information in the HKEY Current Users registry hive to decide who it should launch IE as. This prevents using an impersonated user token to start IE.
The other way is to use System.Diagnostics.Process start to start the process (or run as), but then you can’t control IE as it is running as another user.
Well as it turns out, the solution was staring me right in the face all along and the answer is to use BOTH of these methods, not one or the other.
First we need to launch a new IE process using System.Diagnostics.Process start with different user credentials, then we need to use impersonation to fire up watin in a another thread, attatch to IE and we are away. I have included the code which needs a Refactor and tidy up in a big way, but it works.
It won’t work on Vista with IE 7 because of the attatchto bug, but that is fixed in IE8, Also it is also leaving a process behind when the test finishes.
The impersonation code is from this Microsoft blog http://blogs.msdn.com/jimmytr/archive/2007/04/14/writing-test-code-with-impersonation.aspx
Enjoy,
[TestMethod]
public void TestMethod()
{
SecureString password = new SecureString();
password.AppendChar('p');
password.AppendChar('a');
password.AppendChar('s');
password.AppendChar('s');
password.AppendChar('w');
password.AppendChar('o');
password.AppendChar('r');
password.AppendChar('d');
ProcessStartInfo psi = new ProcessStartInfo();
psi.UserName = "localtest";
psi.Password = password;
psi.UseShellExecute = false;
psi.LoadUserProfile = true;
psi.FileName = "c:\\Program Files\\Internet Explorer\\iexplore.exe";
psi.Arguments = "about:blank";
Process proc = new Process();
proc.StartInfo = psi;
proc.Start();
t.Join();
proc.Kill();
}
private static void DoWorkAs(object o)
{
User u = o as User;
IntPtr hToken = IntPtr.Zero;
IntPtr hTokenDuplicate = IntPtr.Zero;
if (Win32.LogonUser(u.UserName, u.Domain, u.Password, 2 /*LOGON32_LOGON_INTERACTIVE*/, 0 /*LOGON32_PROVIDER_DEFAULT*/, out hToken))
{
if (Win32.DuplicateToken(hToken, 2, out hTokenDuplicate))
{
WindowsIdentity windowsIdentity = new WindowsIdentity(hTokenDuplicate);
WindowsImpersonationContext impersonationContext = windowsIdentity.Impersonate();
// domain\username
Console.WriteLine(" Thread 2 : " + WindowsIdentity.GetCurrent().Name);
IE ie = IE.AttachToIE(Find.ByUrl("about:blank"));
ie.GoTo(@"http://www.google.com/");
ie.TextField(Find.ByName("q")).TypeText("WatiN");
ie.Button(Find.ByName("btnG")).Click();
Assert.IsTrue(ie.ContainsText("WatiN"));
ie.GoTo("about:blank");
//revert
impersonationContext.Undo();
Console.WriteLine(WindowsIdentity.GetCurrent().Name);
}
}
if (hToken != IntPtr.Zero) Win32.CloseHandle(hToken);
if (hTokenDuplicate != IntPtr.Zero) Win32.CloseHandle(hTokenDuplicate);
}
public class User
{
public User(string u, string d, string p)
{
Domain = d;
UserName = u;
Password = p;
}
public string UserName;
public string Domain;
public string Password;
}
public class Win32
{
// P/Invoke snask
[DllImport("advapi32.dll", SetLastError = true)]
public static extern bool LogonUser(
string lpszUsername,
string lpszDomain,
string lpszPassword,
int dwLogonType,
int dwLogonProvider,
out IntPtr phToken);
[DllImport("advapi32.dll", SetLastError = true)]
public extern static bool DuplicateToken(IntPtr ExistingTokenHandle, int
SECURITY_IMPERSONATION_LEVEL, out IntPtr DuplicateTokenHandle);
[DllImport("kernel32.dll", SetLastError = true)]
public static extern bool CloseHandle(IntPtr hHandle);
}
I am pretty proud of our WatiN stack, it is in it’s third major version now and is an absolute joy to work with.
After seeing some other’s code samples online I thought that I should share some of the details so people can improve what they are doing. We recently hit a new one day record with one of our SDE/T’s writing 72 new test cases in a single day.
Our stack is broken down into four key layers, the test, a logical layer, a physical layer and then WatiN itself. If we are working on a Winforms application, we replace WatiN with an in-house developed stack that uses the Windows UI automation API’s. Our test data is stored in a SQL express database and we have a generated data access layer, which keeps the cost of creating CRUD methods very low. One of our tests looks like this:
[TestMethod]
public void VerifyCustomerCreation()
{
Logical.Customer.CreateNewCustomer("Default Customer");
Verification.Customer.VerifyCustomerCreated();
}
And that’s it. The tests are written in the business domain of the application that we are testing, not in a pile of clicks and set values. The next level down the “logical” layer is called by the tests and looks like this:
public static void CreateNewCustomer(string customerName)
{
Physical.Customer.GoToNewCustomerPage();
Physical.Customer.EnterNewCustomerInfo(customerName);
Physical.Customer.SaveNewCustomer();
}
We build our logical layer up by combining smaller atomic actions, this allows us to heavily use the DRY (don’t repeat yourself) approach.
Our physical layer is where the rubber hits the road and it looks like this:
public static void EnterNewCustomerInfo(string customerName)
{
ControlHandler conroller = new ControlHandler();
TestData.Customer customerDetails = TestData.Customer.GetCustomerDetails(customerName);
controller.SetValue(NewCustomerPage.txtFirstName, customerDetails.FirstName);
controller.Invoke(NewCustomerPage.btnSave);
}
The control handler fully abstracts WatiN, or another automation tool so we interact with any control by typically only calling either SetValue, Invoke or GetValue.
To define our controls we have an in-house developed tool where we drag a magnifying glass (Spy++ style) onto a page and it then captures all the controls and gives us a generated static class.
This stack is the result of a lot of investment in our time and represents, in my opinion, state of the art when it comes to web test automation. But then again, I am a bit biased because I wrote it 
.
With the latest commit to the http://code.google.com/p/mcwatin/ repository can now open and close firefox all by itself.
The next feature to add is detection if a browser is open with jssh running and to re-use that browser instead of always launching a new one, or close as appropriate.
On thing that I have noticed is that the lack of a debugger in mono develop on the mac is really slowing me down as I can’t easily follow the code execution.
So I haven’t worked on my WatiN Mac os x port for a few days, but I got back into it last night. The main hurdle at the moment is that the System.Diagnostics.Process class is not fully baked on Mono 2.4 on the Mac platform, because it doesn’t implement the /proc filesystem that linux does.
The correct thing to do would be to learn how the Mach kernel process structure works and fix mono, but I haven’t programmed in non managed C since 1990 and I would be very dangerous, especially at such a low level in mono.
So the first approach was to use the parts of mono that were working, namley Proces.Start() to call a shell script that I wrote to /tmp, then redirect standard out to a file, then parse that file and act accordingly.
StreamWriter sw = new StreamWriter("/tmp/watin-listprocess.sh",false);
sw.WriteLine (@"ps x | grep" + processname + " | grep -v grep > /tmp/watin-processlist.out");
sw.Flush();
sw.Close();
Process shScriptProcess = new Process();
shScriptProcess.StartInfo = new ProcessStartInfo("/bin/sh","/tmp/watin-listprocesses.sh");
shScriptProcess.Start();
A hack, yes, in fact a very messy hack. So messy there had to be a better way.
And there is …
Enter Monobjc. Monobjc is a managed wrapper around the Mac os x Cocoa API’s. A quick search pointed to the NSTask and NSPipe classes as a way to start a process with NSTask, and capture standard out with NSPipe, then parse the result.
A much more technically correct solution.
public static void Main(string[] args)
{
// spin up the objective-c runtime
ObjectiveCRuntime.LoadFramework("Cocoa");
ObjectiveCRuntime.Initialize();
NSAutoreleasePool pool = new NSAutoreleasePool();
// Create our process
NSTask task = new NSTask();
NSPipe standardOut = new NSPipe();
task.StandardOutput = standardOut;
task.LaunchPath = @"/bin/ps";
// add some arguments
NSString argumentString = new NSString("-ax");
NSArray arguments = NSArray.ArrayWithObject(argumentString);
task.Arguments = arguments;
// We have liftoff
task.Launch();
// Parse the output and display it to the console
NSData output = standardOut.FileHandleForReading.ReadDataToEndOfFile;
NSString outString = new NSString(output,NSStringEncoding.NSUTF8StringEncoding);
Console.WriteLine(outString);
// Dipose our objects, gotta love reference counting
pool.Release();
}
So this needs to be fully baked in and then put into my Watin on mac os x port and then it should work stand alone, without shell script assistance.
My presentation at the Microsoft SDC open day alongside Devtest CEO Sarah Richey is now up on Microsoft’s site.
http://www.microsoft.com/australia/services/microsoftservices/sdc_openday.mspx
For my presentation you need to open the “How we do: Testing” video and I am in the last half following Sarah.
Twelve moths ago, before my last project started I went on a journey. The intended destination was test automation nirvana. The way to get there, or so I thought was to combine WatiN with The Braidy Tester’s Automation Stack. The end result, I hoped would be the Deep Thought of test automation. It didn’t quite work out that way, and I would like to share some o the challenges we faced.
I am not going to describe the architecture in detail of the Braidy Tester’s automation stack, as Michael Hunter has already covered that in great detail. What IS important however is the pieces that we chose. The key aspects of the stack that we decided implement were:
Logical.Google.Search("Bruce McLeod");Physical.Google.btnSearch.Invoke();assert statements, loosely coupled verification takes a snapshot of the application, calculates an expected state based on your execution behaviour and then compares it to the actual state after the action is performed.The separation into the logical and physical layers worked exceptionally well. The test cases become very clean and concise. We added another lower level layer called the controller in place of the Application Internals model.
The controller essentially was an abstraction later over WatiN and our control definitions. This makes the entire stack easily portable from one automation technology to another, so the transition will be very easy when the new automation tools ship in the next version of Visual Studio Team Test, if we decide to change.
The idea behind Execution Behaviours is that you use attributes on a method that matches the delegate signature to perform one of the following actions:
ExecuteInSequenceChooseAnyExecuteUntilExecute in sequence is straight forward and is used to compose actions.
[CompositeExecutionBehavior("OpenSearchPage", "WebSearch")]
public static void Search(TestDataProvider dataProvider)
{
TestActionDelegate myDelegate = TestExecutionManager.ExecuteInSequence(Logical.Google. Search(TestDataProvider dataProvider);
}
With delegates being used and the possibility of execution sequence order changing, it becomes necessary to provide inherit record and replay for actions. We chose to use a version of the command pattern and use .net serialization to achieve this. We also had to package up the parameters into an array of objects to the could be serialized. The implementaiton of one of our actions in the physical layer would look something like this:
public static void OpenSearchPage(TestDataProvider dataProvider)
{
// Add this action to the command list and serialize it
object[] parameters = { dataProvider };
ExecutionManager.Add(parameters);
// Open the search page
SearchModel searcher = new SearchModel();
searcher.OpenSearchPage(dataProvider);
}
This then calls the physical layer that actually does the work. All this loosely coupled goodness is great, except that we only ever used the one type of execution behaviour, execute in sequence. As a result our code could have actually looked like this instead if it was hard coded in the logical model.
public static void Search(TestDataProvider dataProvider)
{
SearchModel searcher = new SearchModel();
searcher.OpenSearchPage();
searcher.Search(dataProvider);
}
That code is much simpler and easier to maintain, and removes the method signature matching constraints that delegates impose. For us it would have been a much better way to go, simply because we would have removed the constraints required by functionality that we didn’t actually implement.
In the next post, I’ll run through some of the benefits and challenges we had implementing loosely coupled verification.