Blog
Cucumber is just another Ruby-based test engine which gives the ability to write human language automated tests. But this is only one particular aspect. But there\'s another aspect. Cucumber is just another one auxilary utility as many others. As many others Ruby-based solutions the Cucumber can be integrated into some infrastructure. In particular there\'s ability to define some specific tasks to be done. In addition to this sometimes it\'s necessary to check if overall solution is built without any errors, get the list of the tests marked with some specific tag or list the steps which do not have step definitions implemented or so. All this stuff is quite useful for tests development.
Very often test automation solution becomes so complex that test development require quite strong programming skills. At the same time most of the solutions has a trend to simplify test automation. This can be achieved by various wizards, approaches introduction and devekopment of engines implementing these approaches. In particular,there\'s quite popular approach named keyword-driven testing where tests are actually tthe sequence of keywords structured in tabular form. But there\'s more quirky approach when test instructions are written using "natural" language with corresponding programming implementation. For instance, there\'s engine named Cucumber for Ruby.
Of course XPath locator is one of the most quirky and one of the most precise locator. But this universality is accompanied by the main disadvantage of such locator types. It is slowness. This disadvantage is clearly seen while running the tests under IE while Firefox works with xpath pretty well. This problem is related to internal browser features in particular to the libraries being used for elements location definition. But this is another story. The main thing is that tests which intensively use XPath work extremely slow under IE and this feature is the cause of huge variety of problems related to execution speed as well as quality of the tests itself especially during operations with dynamic content. For this reason CSS locators can be good alternative of XPath. What can we do with CSS locators?
PushButton is one of the simplest controls, but there could be problems even with it. In this blog post we will show several ways of how to perform a non-standard Click() action when standard Click can not be used.
GUI level automated testing has a lot of surprizes related to interaction with window objects. The main problem is that each automation tool has its own set of the most effective solutions to the problem of window definitions maintainability. But these are the most effective solutions for each particular case ( not in general ). Nevertheless, there are some mechanisms which are common to a wide range of tools. Or at least there are analogs. For example there is such approach as windows definitions mapping which provides the ability to set some alias into correspondence to actual window definition. Such solution implementation in TestComplete has one key disadvantage: in case of windows hierarchy modifications for some particular object there is necessity to re-map all child objects. The alternative to mapping was introduced in TestComplete version 6. There was an Alias functionality providing the ability to construct mapped objects hierarchy. But this solution has another disadvantage: slow performance. So, we need some mechanisms allowing to minimize time costs for window definitions modification in case of UI changes. Let's examine this problem on some particular case.
The simplest and most obvious way to close a window by SilkTest is using Close() method. However, sometimes this method doesn't work. For example, try to open Notepad, write some text there and then execute the following code
[ ] Notepad.SetActive ()
[ ] Notepad.Close ()
Notepad will show a message box about changes made and will wait for user's actions, and SilkTest will post an error message to the log
*** Error: Window cannot be closed
Of course, such situations should be foreseen and processed in scripts, but what if we need to close a window anyway? In this case we can use Kill() method which simply kills a window. For some reason this method is not described in SilkTest help, but it can be found in the winclass.inc file.
[ ] Notepad.SetActive ()
[ ] Notepad.Kill ()
A new 2009 year knoks the door and the team of Automated Testing Service Group wishes everyone Happy New Year! Let next year bring more possibilities and achievements! Let the success follow you everytime.
Sometimes code recorded by TestComplete does not replay as it is expected. One of the problem methods is Drag() method, which allows to move objects to other positions. In this case we can use methods MouseDown() and MouseUp() of Sys.Desktop object to create own dragging function.
function DragDrop(obj, deltaX, deltaY)
{
var iX = obj.ScreenLeft + obj.Width/2;
var iY = obj.ScreenTop + obj.Height/2;
Log.Picture(obj.Picture(), "Object to be moved");
obj = Sys.Desktop.ObjectFromPoint(iX + deltaX, iY + deltaY);
Sys.Desktop.MouseDown(VK_LBUTTON, iX, iY);
obj.HoverMouse(obj.Width/2, obj.Height/2);
Sys.Desktop.MouseUp(VK_LBUTTON, iX + deltaX, iY + deltaY);
}
This function presses left mouse button in the center of the object to be moved, then moves mouse cursor to the new destination and releases pressed button. Here is an example demonstrating moving of icons in the QuickLaunch toolbar.
function Test3()
{
var w1 = Sys.Process("Explorer").Window("Shell_TrayWnd").Window("ToolbarWindow32", "Quick Launch");
DragDrop(w1, -30, -20);
}
One of the most frequently asked questions about software testing automation is "where should I start learnig an automation tool?". In this blog post we will try to give an answer to this question without using a concrete tool.
One of the most serious problem of automated tests ( especially GUI level tests ) is synchronization between test execution and application under test work. In other words, all actions being performed by the automated test have to be executed exactly at the moment when application under test is on the correct state allowing to perform required actions. Otherwise we are at risk to come across the situation when test tries to click on some object, enter some text while the form to perform these operations on is simply not available. As the result, our test goes by its fixed steps but the results and system behavior is unpredictable. And if at the same time there are no recovery scenarios the whole test set execution may be failed at once.
Every so often during tests automation we may encounter steps description like "Repeat steps 1-12" or even more interesting like instructions to repeat all steps using some specific settings. It means that we have to duplicate some code during automated tests development. But excessive code duplication may cause a number of maintainance problems. Any changes have to be made in all repetitive code occurences. And this makes additional time loss. It can be avoided in the following ways:
From time to time while reading different publications we may find the opinion that any "heavy-weight big vendor" automated testing tool ( actual tool names are usually omitted ) is associated with such thing as unmaintainable tests. But at the same moment any hand-made solution or even simple library is positioned as something flexible and easy adaptable. Of course, I also prefer taking something little and simple and using it effectively rather than taking something heavy-weight and thinking hard about how to bind it to my processes.
During development of automated tests as well as any other program components we have to make our code satisfy the following characteristics:
- Readability
- Extensibility
- Transportability
- Optimality
- Correspondence to requirements
- Maintenability
- Others ( some project-specific features )
Test automation success highly depends on the way the tests are designed. Design defines how fast automated tests can be developed, how these tests are suitable to read and understand the concept, how they can localize the problem and how they can reveal problems at all. All these points are highly depend on tests structure. It means that test design takes essential part in test automation. It is test scenario or test workflow description which is basis for automated test implementation. That's why direct impact on test design stage may highly improve test automation process. Well, in order to improve test automation any test scenario requires the following:
JScript operator is used for getting type of the variable. There are six possible values that typeof returns: "number," "string," "boolean," "object," "function," and "undefined".
In this post we will improve typeof operator so that it can also return "date" and "array" values for corresponding data types.
There are undocumented features in any computer program. Some of them are added specially (e.g. Easter Eggs), other can be programmers' mistakes, and some of them are just unimplemented features.
In this article we will describe one of the SilkTest's undocumented features, the 2nd argument for LogError function.
In this post you will find an example of the function, which delays script execution and displays the time left for execution in the TestComplete Indicator.
Automated Testing Service Group wishes you a Happy New Year!
May all your dreams come true in 2008!
ListPrint(lsOut)
However, this event will work only if unexpected window prevents TestComplete to work with application. In case of non-modal windows, or if the window doesn’t affect tested application, this event will not occur and TestComplete will continue working.
There are several ways of the opening different files in SilkTest. In this blog post we'll describe 3 ways and when it is better to use them.
A strange behavior of TestComplete was encountered when trying to work with standard IE File Download window. This window appears when user tries to download a file from Internet.
The problem was that TestComplete logged about successful clicking on the Open button, however no expected result happened and window just stayed as though no action was done.
When recording actions in TestComplete, it uses ClickButton() method for clicking standard push buttons.
For example,
var w = Sys.Process("WindowsApplication3"). WinFormsObject("Form1");
w.WinFormsObject("button1").ClickButton();
It is recommended to replace it with method Click() because standard button can be replaced with own-drawn one, or with some third-party control with the same name. In this case ClickButton() method won't work properly.