The Dynamic Programmer - LightweightTestingFramework

Tuesday, June 09, 2009

Lightweight Test Automation Framework June Update

These guys are working hard and given us releases almost every month. I ‘m happy to see some of the feedback from the community incorporated into the Framework.

Go ahead download it from CodePlex and give it a try to test your web application.

Tuesday, June 09, 2009 5:48:03 PM (Eastern Standard Time, UTC-05:00) by Hernan Garcia

Comments [0] - Trackback
Lightweight Testing Framework | Testing

Friday, March 27, 2009

Lightweight Test Framework, attaching to a new window after window.open

In a previous post I mention about a fix to been able to open a new window both in IE and Firefox using the Lightweight Test Framework.

Today I want to talk about how to hook into the newly opened window or any other window opened by the testing framework.
Let me said this, it’s not very difficult but is kind of convoluted, I won’t be surprised if there is a better way to do this, but I can’t seem to find it.

The key resides in the BrowserCommandTarget object. This object has a property WindowIndex that maps to the index of the _windowCollection array on the client side code (the JavaScript implementation of the framework).

The next thing we need to do is figure out how to send a BrowserCommand to this window, and sure enough BrowserCommand has a target property that takes a BrowserCommandTarget.

So here is the code to click a button in a window that was open after calling window.open in the main window.

    1     [WebTestMethod]
    2     public void OpenNewWindow()
    3     {
    4         var page = new HtmlPage("../SiteToTest/HTMLPage.htm");
    5         page.Elements.Find("openWindow").Click(WaitFor.None);
    6 
    7         var handler = new BrowserCommandHandler
    8                           {
    9                               PopupAction = PopupAction.None,
   10                               RequiresElementFound = true,
   11                               ClientFunctionName = BrowserCommand.FunctionNames.ClickElement
   12                           };
   13         var target = new BrowserCommandTarget
   14                         {
   15                             WindowIndex = 1,
   16                             Id = "clickedOnTheSecondWindow"
   17                         };
   18         handler.SetArguments(false);
   19         var command = new BrowserCommand(BrowserCommand.FunctionNames.ClickElement)
   20                           {
   21                               Description = "Click",
   22                               Target = target,
   23                               Handler = handler
   24                           };
   25         var info = page.ExecuteCommand(command);
   26     }

Lines 4 and 5 is just the normal way you click in an element. In this case I look for an element with the Id of “openWindow” and do a Click. This is the html of the page we are testing.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> 
<html xmlns="http://www.w3.org/1999/xhtml">

<head>
    <title>My page</title>

    <script>   
        function doConfirm() {

            if (confirm("Do you confirm this?")) {

                document.getElementById("mySpan").innerHTML = "OK";

            } else {

                document.getElementById("mySpan").innerHTML = "CANCEL";

            }

        }


        function openNewWindow () {

            window.open("HTMLPage.htm","_blank","toolbar=no",false);  
         }
  
        function addsAMessage () {

            document.getElementById("message").innerHTML = "This message should only appear on the second window."

         }         
    </script>

</head>

<body>

    <input type="button" name="myButtom" value="Do confirm" onclick="doConfirm();" />

    <span id="mySpan"></span>

    <input type="button" name="openWindow" value="Open new window" onclick="openNewWindow();" />

    <input type="button" name="clickedOnTheSecondWindow" value="Clicked on the second window" onclick="addsAMessage();" />
    <span id="message"></span> 
</body> 
</html>

After this page opens I want to click the button with the name “clickedOnTheSecondWindow” in the newly opened window. For that I create a BrowserCommandHandler that knows how to handle the onclick event. A BrowserCommandTarget with the Id of the element to be checked and I pass the index (1) for the newly opened window, the original window already opened in the test frame is index 0.
Then I create a BrowserCommand and assign the target and the handler to it.
Finally I call ExecuteCommand in the page object passing the newly created command.
This may sound counter intuitive since page is the same object we used before to click “openWindow” in the test frame. But page.ExecuteCommand takes all the data from the passed in command argument. I consider that it should be a better way to do this and maybe this is a smell on the API or me not figuring out the right way to use it.

I mentioned before that BrowserCommandTarget.Id takes the Id of the element, I’m sure that you notice that none of the buttons have an Id but only a name. The framework will first search by Id and then by name always using the value passed to the Id property.

So far I haven’t figured out how to make an assertion in the new window though, I guess that will be something to deal with in another post.

Friday, March 27, 2009 4:29:00 AM (Eastern Standard Time, UTC-05:00) by Hernan Garcia

Comments [0] - Trackback
Lightweight Testing Framework | Programming | Testing | Tools

Wednesday, March 25, 2009

Lightweight Test Framework, fixing how to handle window.open

As I mentioned in a previous post I have been playing with the Microsoft Lightweight Test Automation Framework.

The Lightweight framework handle alert and confirms without any problem, both in IE and Firefox out of the box. I guess it won’t be an issue on the Mac either. Now window.open is another issue, a JavaScript error was thrown in both browsers.

So here is how I fix it so far (so far because I still need to deal with a nasty bug on Firefox).

Window.open is not working (and a solution).

After digging around and thanks to Firebug (and at a lesser degree, the new Developer tools for IE8) I found that the problem seems to be in two places. Wait until the end of the post to change anything on your files.

My first approach.

First open the following file (in the source code solution for the framework).

Engine/Resources/ScripFiles/BrowserFrame.js

We will change the following line:

frame._originalOpen = frame.open;

this._originalOpen = frame.open;

Engine/Resources/ScripFiles/TestExecutorBase.js

Search for openWindowAndRegister: this is the function that will be assigned to window.open by the framework to handle the calls get a new window object and add it to the browser windows collection of the TestExecutor object.

We will change the following line:

var newWindow = TestExecutor.get_activeWindow().get_activeFrame().get_jsFrame()._originalOpen(url, name, features, replace);

with the following code:

var activeWindow = TestExecutor.get_activeWindow();
var activeFrame = activeWindow.get_activeFrame();
var newWindow = activeFrame._originalOpen(url, name, features, replace);

The temp variables are there just to help when debugging. Notice that we are calling _originalOpen on activeFrame and not activeFrame.get_jsFrame()

Now this will make window.open functions work in IE but not in Firefox where I get an “Illegal operation on WrappedNative prototype object" exception, this seems to be a known regression on Firefox since at least version 1.07.

Upon thinking about this I notice that we should be able to actual use window.open directly inside openWindowAndRegister.

So here goes the solution that works, I kept the changes to BrowserFrame.js but the changes to TestExecutorBase are now as follow replace :

var newWindow = TestExecutor.get_activeWindow().get_activeFrame().get_jsFrame()._originalOpen(url, name, features, replace);

with the following code:

var newWindow = window.open(url, name, features, replace);

window.open returns a windows object and them we can register it to the _windowCollection internal array of the TestExecutor. So far I like this solution, now I need to figure out how to write test against this new window. I guess I will leave that for another post.

Wednesday, March 25, 2009 1:20:00 AM (Eastern Standard Time, UTC-05:00) by Hernan Garcia

Comments [0] - Trackback
Lightweight Testing Framework | Programming | Testing | Tools

Tuesday, March 24, 2009

Microsoft Lightweight Automation Framework: Writing your tests in a different web

UPDATE: There is another way to do this. Check this post from the QA team blog.

This is a quick post. In the samples for the framework the test are written in the same system to test.

This is not terrible, since you can easily remove those files for the final compilation, but I prefer to have my test in a different project. Well that’s very easy to do. Just create another web application and follow the same conventions that in the sample to create your test.
Add a reference to the framework, create an App_Code folder if you don’t have one, add a Tests folder inside and create all your test fixtures in it.

Them when loading the pages to test just use a relative path.

The important thing is to run the test runner under the same domain of the app you want to test.

Tuesday, March 24, 2009 5:00:00 AM (Eastern Standard Time, UTC-05:00) by Hernan Garcia

Comments [0] - Trackback
Lightweight Testing Framework | Programming | Testing | Tools

Monday, March 23, 2009

Microsoft Lightweight Test Automation Framework: Fixing window.open errors

I have been playing with the Microsoft Lightweight Test Automation Framework, that’s a mouthful for the Microsoft’s Web testing framework.

I think that (in general) looks like a nice alternative to some of the other frameworks around (like Watir or Selenium). I will try to give a quick overview of what I have been using so far and what I like and don’t like.

For more information on the framework, take a look at the Forum.

What I like.

Open Source (you can download the source from Codeplex).
A first sample is included
Since the library is written in c# you can write the test in your language of choice inside VS. This may encourage to write the UI test first. This can be even written by the same developer that is implementing the UI.
Nice API, providing methods, properties and objects that represent an HTML page and help to navigate the DOM.
No problem handling JavaScript’s alert and confirm dialogs.
Look’s to been able to handle asynchronous Ajax calls (I haven’t tried it yet).
Cross browser, cross platform.

What I think needs improvement.

Documentation (*).
Some internal objects should be public, like the BrowserInfo. (*)
Setup, Teardown attributes (not very high on my list, but may be useful). (*)
Provide a way to attach to a new window, or even Assert that a new window was open. (The JavaScript engine already contains a collection of newly opened windows, so this should be easy to implement).

*. The Roadmap document mention these issues as forthcoming or in consideration.

In following posts I will try to find solutions to some of these issues.