Sunday, February 16, 2014

How to run some code before each test?



Let’s suppose you need to run some general “code” (a few commands), like a login process or a button click before every test in siesta. You want that each and every test in your test suite will be executed from where the “general code” stopped.

For example, assume that there are two types of tests suites – the first test suite is running on a specific window, and the other is running from a different window. The windows are two different windows entirely, and each of them can be reached from a “main menu” which has two buttons – one button for each window. This means that you need a click on button “x” to be performed before the first type of tests, and a click on button “y” to be performed before the other type of tests. 

In siesta there isn’t yet a solution for this kind of problems, but we can overcome them by adding a new test class (extending the test class) and by overriding the isReady function, so before each test will start to run the code in the new test class will be executed. 

Setting the environment for a new test class

Now it’s time to configure the environment to use a new test class. There are several phases to do this:

1       1. You need to add the test class name to the harness.configure function in index.js file:

Harness.configure({
    title       : ‘This is my test Suite’,
    testClass  : Siesta.Test.Whatever,
});

NOTE: the new test class MUST extend the siesta test class, so its name should be inside the siesta name space. For example, names like “This.Test.Class” will not work, but names like “Siesta.Test.Whatever” will.

         2. You need to create a file which will contain the new test class, and locate it in the webapp folder. Since all the paths are relative to the index.js file, you can create it in the same folder as index.js located in.

3       3. Add this line (which is the new file you created) to the index.html file, right after the “siesta-all.js”  file and under “script” tags:

<script type="text/javascript" src="Pre-Code.js"></script>

          4. In the new class file, you need to override the “isReady” function. You can read more about the function here: http://www.bryntum.com/docs/siesta/#!/api/Siesta.Test-method-isReady

There are a few important things to note when using siesta to test ExtJS and when wanting to use Ext commands or siesta commands (like Ext.ComponentQuery or t.click):

  • The “isa” value should be Siesta.Test.ExtJS since we are testing ExtJS application.
  • When using Ext commands, instead of the usual “Ext.ComponentQuery” you should use “this.getExt().ComponentQuery”.
  • When using variables that are defined in the preload files, you should add “this.global” before their names.
  • When using siesta methods (like click or chain), you should add “this” before the method instead on the usual “t”.
  • After you finish writing the code you want to do before each test, don’t forget to set the value of “isCustomSetupDone” to true – this will start the test itself.

Saturday, January 25, 2014

Callback Method

If you’re a frequent siesta user, you are probably familiar with the “callback” parameter – you can find it in almost all common methods like “click”, “type”, “drag” etc.

Here is the official documentation:

·         callback : Function (optional)
A function to call after click.

In other words, the callback is a method to be called after the current operation is complete.

To better understand that let’s stop for a moment and explain how these common methods behave. When you call the “type” method in your test code some ‘magic’ happens: the browser will start the operation of typing as you requested and running the code that should run as a result of this. At the same time, your test code will continue to run and the next line in your code will be executed. This is best described as an asynchronous method because it is running “in the background” while your next line of code is already being executed.

Now suppose you want a click to be performed after a type operation. That means that you want the test to “wait” and execute the click only after the typing operation is complete. In order to do that you need to provide a function as a callback to the type operation, so when the typing operation is complete it will call this function which in our examples will perform the click.

Let’s take a look at some examples:

if you want to run click after type you can provide the “next” function as a callback in the type method:

t.chain(
       function (next) {
             t.type(typeField,'text to type',next);
       },
       function (next) {
             t.click(button, next);
       }
);      
                    
You can also call the “next” function yourself after a method that does not have a callback option, like the diag method:

t.chain(
          function (next) {
                  t.diag('Im going to click a button!');
                  next();
          },
          function (next) {
                  t.click(button, next);
          }
);
                          
if you want to write a function of your own which uses the callback option – for example, a function that clicks on a certain button, you can write this in your preload file (if you don’t know what a preload file is or why do you need it – go back to the previous posts):

function clickOnFooButton (t, callback) {
var fooBtn = Ext.ComponentQuery.query(‘button[itemId=Foo]’);
    t.chain(
function (next) {
                  t.click(fooBtn[0],next)
            },
            function (next) {
                  callback();
            }
    );
};

And on your test file you can simply call the “clickOnFooButton” function the same way as you would click on a button:

StartTest(function(t) {
     t.chain(
            function (next) {
                  clickOnFooButton (t,  next);
            },
            function (next) {
                   t.type(typeArea,‘hello’); 
            }
     );
};


This will make the test to click on the button which has the itemId of “Foo” and only after that, will type ‘hello’ to the typeArea. 

Sunday, December 1, 2013

Running Siesta from a remote computer

How to run Siesta from a remote computer using Selenium Webdriver:


Suppose you have a machine which has linux file system and you write your test on it; But the test you execute need to run on a windows machine (for all browsers support, or from any other reason). 
Now you want to run a command in your linux machine, that will execute remotely all the desired tests on the windows machine and send back to the linux the alerts regarding which test passed and which tests failed.

On the "Server"

  1. On the “server” – where you want to run the browser (aka - the windows machine) copy the siesta files and folders (the latest version which you can get from here: http://www.bryntum.com/customerzone/home.php ) to c:\program files\
  2.  Install java (if not installed) from: http://www.oracle.com/technetwork/java/javase/downloads/index.html
  3. Access the siesta directory from cmd, and run the following commands:
        # cd c:\Program Files\siesta-2.0.4-standard\bin
        # webdriver-server -port 4444

On the "Client"

On the "client" - (in this example, it's the linux machine) navigate to Siesta's installation folder (the webapp directory) and cd to webapp/bin.

From the bin directory, execute the command:

# webdriver [the URL of your siesta GUI] --host ["server" - windows host name or IP address] --port 4444 --browser=[which browser to run on the windows client, i.e: firefox, chrome, ie, safari ]


Additional Flags

If you want to run just one test you can use the “--include” flag. If you want the output to be in JUnit format  you can use the “--report-format” and “--report-file” flags. 

For Example:

# webdriver http://IP/siestaTests --include=MytestFile.t.js --host YourHostName --port 4444 --browser=ie --report-format=JUnit --report-file=MytestFile_log_

For IE

This configuration works fine on firefox and chrome, but for IE there is some adjustments to make:
  1. Download the driver from here: https://code.google.com/p/selenium/downloads/list
  2. Copy to the windows machine (to C:\installations\selenium-2.37.0).
  3. Add this location in the PATH environment variables on your windows machine.
  4.  Set the protector mode: open the IE browser, choose "Internet Options..." from the Tools menu, and click on the Security tab. For each zone (4 zones usually), there will be a check box at the bottom of the tab labeled "Enable Protected Mode" – all of them should be the same, all checked or all unchecked.
  5. Set the browser to IE9 mode (press F12 and change the browser mode), and place it on top of all other windows. 

In order to make IE run in standard mode, add this line to the index.html file in webapp directory, right after the <head> tag:



Good luck!

Saturday, November 23, 2013

Siesta - Getting Started

Siesta - writing automated tests

Since this page will NOT teach you all you need to know about siesta configuration, settings and functions I strongly recommend that you spend some time reading about siesta.
Here are a few useful links:


Siesta Basics (Briefly)

There are 3 files that needs to be modified when writing a new test in siesta:
  1. index.js
  2. preload.js – This file is loaded before your tests run.
  3. your test file (you can pick any name you want, but keep it meaning-full and in order) for example - Mytestfile.t.js
The files are located in the siesta installation folder:
In your webapp directory you can place your new siesta tests and directories.


index.js

Configuration file for the siesta. In order to view and execute a test, you need an entry for your test file in index.js

preload.js (not mandatory)

In your index.js file you can define which files should be loaded before your tests run. You can name it anyway you want, “preload.js” is a nice name. Though this file isn’t mandatory once you start developing more tests you’ll need a common place to store common functions and variables. This is why it is very useful.  


Writing a Test in Siesta - an Example

Create a test file in your webapp folder – Mytestfile.t.js
Code that you think you will use again (in other tests) should be added to your preload.js file.

For example, write a function that finds the submit button on your page and clicks it. (You’ll probably need to click the submit button in many of your tests).

function clickOnButtonSubmit (t, callback) {

 // Searching for our Submit button
 var button = Ext.ComponentQuery.query('button[action=submit]');
 t.chain( 
  function (next) {
   // Clicking the button 
   t.click(button[0],callback);
  });  
};


Call the function in your test file.
StartTest(function(t) {

 t.chain(
  function (next) {
   clickOnButtonSubmit(t,next);
  }
 );
});


Add the test file to index.js
var Harness = Siesta.Harness.Browser.ExtJS;
Harness.configure({
 title  : 'Awesome Test Suite',
 hostPageUrl : '../yourapp/index.html',
 preload  : [ 'preload.js' ]  // Path is relative to the location of the index.js file
});
Harness.start(
 'Mytestfile.js', // Path is relative to the location of the index.js file
);



Open siesta UI and execute your test!