Checkout our latest tutorial: Object Map Tips & Tricks
Request your free 30 day Squish evaluation
Learn more about Squish
Other Squish Resources (videos, tech articles, user communities and more)
Squish uses the Object Map to store select properties, and their values or othe object real name, which is then referenced by scripts using a symbolic name.
{text='Yes' type='QPushButton' unnamed='1'
visible='1' window=':Address Book - Delete_QMessageBox'}
:Address Book - Delete.Yes_QPushButton
Should the Yes in the button change to Confirm or OK, simply update the property value in the Object Map, and no changes are required in your scripts.
In this case as well, the ‘window’ property value is dynamic, and can be handled with a regular expression or wild card from within the Object Map (or within the script directly) If using an image-based solution, such dynamic changes become a maintenance nightmare.
Changes to objects in an application are handled quickly and from a central location – no updating screenshots or XPaths to objects (however XPath is supported as an option). Additional properties can be added, or undesired or unneeded properties can be removed from an object’s real name as well. The key is the extensive flexibility the Object Map profiles, along with the accuracy with which it can find and interact with objects. Learn more about object vs image-based object recognition
While recording, the Control Bar contains an Insert Script Comment button
Once you complete your recording, by clicking Stop, the comment appears within your script. The following example’s comment is: # Adding a new entry
def main():
startApplication("AddressBookSwing.jar")
activateItem(waitForObjectItem(":Address Book_JMenuBar", "File"))
activateItem(waitForObjectItem(":File_JMenu", "New..."))
activateItem(waitForObjectItem(":Address Book - Unnamed_JMenuBar", "Edit"))
activateItem(waitForObjectItem(":Edit_JMenu", "Add..."))
# Adding a new entry
type(waitForObject(":Address Book - Add.Forename:_JTextField"), "sam")
type(waitForObject(":Address Book - Add.Forename:_JTextField"), "<Tab>")
type(waitForObject(":Address Book - Add.Surname:_JTextField"), "smith")
type(waitForObject(":Address Book - Add.Surname:_JTextField"), "<Tab>")
type(waitForObject(":Address Book - Add.Email:_JTextField"), "sam@smith.com")
type(waitForObject(":Address Book - Add.Email:_JTextField"), "<Tab>")
type(waitForObject(":Address Book - Add.Phone:_JTextField"), "123.123.1234")
clickButton(waitForObject(":Address Book - Add.OK_JButton"))
Imagine you want to verify or inspect an item in a menu, drop down list, context menu, etc. You click the menu, and then the Pick tool. Clicking away makes the menu close. How can you possibly ‘pick’ such an object?
As learned in a prior Squish tip of the week, your Squish IDE can create tests and interact with applications through a remote connection. Read more here: Squish tip of the week: Create tests against a remote environment
The Squish IDE now displays the menu item in the Application Objects tree with its associated properties and values in the Properties list.
Using Squish’s Application Context, you can capture memory usage and other key information about your application at runtime.
With each Squish edition, or technology supported, you can us the corresponding toolkit’s API from your test scripts.
This gives you access to your application, and to make calls, beyond what can be done from your application’s user interface alone.
Take for example the Java Convenience API
In JavaFx applications you can have more than one top-level window.
How can you ensure the proper top-level window is in front before interacting with it? Use the .toFront() call.
For example, given a symbolic name of MyWindow1, the line would simply read MyWindow1.toFront()
Search doc.froglogic.com for your toolkit’s convenience API, or your the AUT toolkit API documentation.
(Near) endless possibilities!
Resizing a docked window isn’t always as simple as it may seem.
Docked windows often change height and width as well as their docked location. The control or widget can also be more complex, not resizing with a simple MouseDrag used with non-docked windows.
The example below illustrates how to resize a docked window when working with the Qt Widget QDockWidget:
# About Example
# Supply specific QDockWidget's symbolic or real name
# (in this sample application QDockWidget is ColorSwatch)
# change_* functions take three parameters: QDockWidget
# as o, resize value as xdiff, snooze in seconds
# (optional) as snoozeFactor
def main():
startApplication("mainwindow")
dockToResize = waitForObject(":Qt Main Window Demo.White Dock Widget [*]_ColorSwatch")
change_height_on_top(dockToResize, -20)
change_height_on_top(dockToResize, 20)
change_height_on_bottom(dockToResize, -20)
change_height_on_bottom(dockToResize, 20)
change_width_on_left(dockToResize, -20)
change_width_on_left(dockToResize, 20)
change_width_on_right(dockToResize, 20)
change_width_on_right(dockToResize, -20)
def change_height_on_top(o, xdiff, snoozeFactor = 0):
snooze(snoozeFactor)
mousePress(o, 50, -2, MouseButton.LeftButton)
start = 0
end = xdiff
step = 1
if xdiff < 0:
step = -1
for i in range(start, end, step):
mouseMove(o, 50, -2 + i)
mouseRelease()
snooze(snoozeFactor)
def change_height_on_bottom(o, xdiff, snoozeFactor = 0):
snooze(snoozeFactor)
mousePress(o, 50, o.height + 2, MouseButton.LeftButton)
start = 0
end = xdiff
step = 1
if xdiff < 0:
step = -1
for i in range(start, end, step):
mouseMove(o, 50, o.height + 2 + i)
mouseRelease()
snooze(snoozeFactor)
def change_width_on_left(o, xdiff, snoozeFactor = 0):
snooze(snoozeFactor)
mousePress(o, -3, 50, MouseButton.LeftButton)
start = 0
end = xdiff
step = 1
if xdiff < 0:
step = -1
for i in range(start, end, step):
mouseMove(o, -3 + i, 50)
mouseRelease()
snooze(snoozeFactor)
def change_width_on_right(o, xdiff, snoozeFactor = 0):
snooze(snoozeFactor)
mousePress(o, o.width + 3, 50, MouseButton.LeftButton)
start = 0
end = xdiff
step = 1
if xdiff < 0:
step = -1
for i in range(start, end, step):
mouseMove(o, o.width + 3 + i, 50)
mouseRelease()
snooze(snoozeFactor)
For more information, and a more extensive example, see Article – Resizing Docked Windows (QDockWidget)
Switch between applications (for recording or playback) using Application Context.
All scripts, test data, verification points and even gestures in your Test Suite Resources are available to all Test Cases in your Test Suite.
With Squish’s real-world scripting language support of Python, JavaScript, Perl, Tcl and Ruby, your scripts, even those independent of Squish, are also available using Squish’s Global Script view.
Applications often have a set of business rules; rules that govern how an application should react based on a given set of input or actions. Or as Wikipedia defines it:
A business rule is a rule that defines or constrains some aspect of business and always resolves to either true or false. Full definition
Take a simple set of steps, perhaps even a Snippet of a Test Case, let’s say lines 7 – 10 in the following example:
def main():
startApplication("AddressBookSwing.jar")
activateItem(waitForObjectItem(":Address Book_JMenuBar", "File"))
activateItem(waitForObjectItem(":File_JMenu", "New..."))
activateItem(waitForObjectItem(":Address Book - Unnamed_JMenuBar", "Edit"))
activateItem(waitForObjectItem(":Edit_JMenu", "Add..."))
type(waitForObject(":Address Book - Add.Forename:_JTextField"), "sam")
type(waitForObject(":Address Book - Add.Surname:_JTextField"), "smith")
type(waitForObject(":Address Book - Add.Email:_JTextField"), "sam@smith.com")
type(waitForObject(":Address Book - Add.Phone:_JTextField"), "123.123.1234")
clickButton(waitForObject(":Address Book - Add.OK_JButton"))
Given answers to the above set of questions, you can begin compiling a collection of data to validate the business rules.
| field | input | result_details | comments | |
| 1 | Forename | sam | Expected Result: input accepted without error | |
| 2 | Forename | s@m | Special characters not permitted in Forename field | Expected Result: Warning message appears immediately |
| 3 | And | so | on | … |
Use the Make Code Data Driven wizard to give yourself a jump start.
Then
def main():
startApplication("AddressBookSwing.jar")
activateItem(waitForObjectItem(":Address Book_JMenuBar", "File"))
activateItem(waitForObjectItem(":File_JMenu", "New..."))
activateItem(waitForObjectItem(":Address Book - Unnamed_JMenuBar", "Edit"))
activateItem(waitForObjectItem(":Edit_JMenu", "Add..."))
for record in testData.dataset("businessRules.tsv"):
field = testData.field(record, "field")
input = testData.field(record, "input")
result_details = testData.field(record, "result_details")
comments = testData.field(record, "comments")
textField = waitForObject(":Address Book - Add.%s:_JTextField" % field)
textField.setText("")
type(waitForObject(textField), input)
waitFor("object.exists(':Address Book - Add.%s_Warning:_JLabel' % field)", 20000)
test.compare(findObject(":Address Book - Add.%s_Warning:_JLabel" % field).text, result_details, comments)
There’s a wealth of Squish & Automated GUI Testing information at your finger tips. Sometimes the key is simply knowing where to look!
When working with multiple applications, or multiple windows in a single application, you can tell Squish to bring the desired window to the foreground before working with the window.
This applies to many different technologies or toolkits.
For example, when working with NSWindow on Mac OS X (Cocoa), given the name or title of the window, you can do the following:
def main():
startApplication(...)
...
objName = "{title='MyApp Window #1' type='NSWindow'}"
waitFor("object.exists(\"%s\")" % objName, 20000)
nsw = findObject(objName)
nsw.makeKeyAndOrderFront_(nsw)
Read more about this Mac OS X Cocoa example, or other examples in the following Knowledgebase articles:
Remember; we’re always adding to our knowledgebase and other online resources to provide you with the most current and helpful information!
Identifying and separating test failures related to defects versus flaky tests isn’t always as straight forward as it may sound.
Time. Exponentially impacted time.
When test failures are not handled intelligently, manually troubleshooting and distinguishing the two can lead to a time engulfing maintenance nightmare.
Re-run failed tests multiple times. Either using your automated batch, CI process or directly from your scripts, logging then in the results the failure occurrence rate.
tests are most effective when produced with a specific goal in mind, not a series of items to validate along the way. Having longer tests with various dependencies creates a more difficult to maintain framework. This also lengthens the time investment required to identify the source of each issue – exactly where, what went wrong. As your test framework grows, the maintenance investment grows.
Think in terms of a Behavior Driven Test:
Too many Given’s and When’s can muddy the waters – making it more time consuming to pin point the root cause of the issue.
Start small, start smart, refine… then expand!
Remember; we’re always adding to our knowledgebase and other online resources to provide you with the most current and helpful information!
As with many things in Squish – the sky’s the limit using Squish’s supported scripting languages.
Check out an example script and function demonstrating how to retrieve process information on the Windows operating system
About two years after the release of Squish 5.0, we are proud and excited to make available a BETA of Squish 6.0 to you.
The main new features of this release are fully integrated support for Behavior Driven Development and Testing (BDD) as well as major improvements to Squish’s reporting capabilities.
You can read the full announcement at http://www.froglogic.com/news-events/index.php?id=squish-6.0.0-beta-released.html.
A quick video introduction to Squish 6.0 and BDD can be found at http://youtube.com/embed/62Vrnb21hio?vq=hd1080&autoplay=1&rel=0&showinfo=0&autohide=1.
We will also host a live webinar showcasing what’s new in Squish 6.0 shortly. You find details about this in the above announcement.
We are looking forward to your feedback which we happily accept at squish@froglogic.com.
Have any existing scenarios in Gherkin? If not, no worries, creating them is as easy as writing in your native language.
Feature: Valid conversion
Scenario Outline: Convert meter in centimeter
Given the Unit Converter is running
When I enter 378.9
And choose to convert from Meters
And choose to convert to Centimeters
And click Convert
Then 37890 should be displayed in the result field
That’s it! Your BDD scenario is automated. Just click Run to play it back!
BDD tutorials by Squish Edition
- Select your Squish edition-specific tutorial (i.e. Qt, Android, Java, etc.) from this list of tutorials
- Click Tutorial: Designing Behavior Driven Development (BDD) Tests
BDD tests can span multiple platforms. Watch this great video on how you can execute BDD tests across multiple platforms.
Segmenting from a past blog post, Scripting with the help of the Squish Script Console, an enhancement to the Squish Script Console in 6.0 makes current variables and their values available from the console.
Now manually scripting or troubleshooting your scripts are that much easier!
The example below illustrates using the record variable value in a statement within the Squish Script Console to validate expected output and syntax.
New features! Features not even in Development (yet).
If you haven’t already, request an evaluation of Squish 6.0beta, and begin automating features sooner with the introduction of BDD automation.
How about tests where a password is required?What if I have to manually configure something as part of a test?
Use Squish’s testInteraction Functions to allow user-input points during playback.
The following example uses a simple Java Swing application available for download from http://www.codejava.net/download-attachment?fid=154, or if you prefer to download directly from our blog: SwingJPasswordFieldDemo
As you can read more about here, testInteraction has many functions available. The example below demonstrates pausing, providing the end user with a message, and an OK button for continuing on line 7.
function main() {
startApplication("SwingJPasswordFieldDemo.jar");
clickButton(waitForObject(":Swing JPasswordField Demo Program.OK_JButton"));
waitFor("object.exists(':Message.Wrong password!_JLabel')", 20000);
test.compare(findObject(":Message.Wrong password!_JLabel").text, "Wrong password!");
clickButton(waitForObject(":Message.OK_JButton"));
testInteraction.information("Please enter the password and click OK on this dialog to continue.");
clickButton(waitForObject(":Swing JPasswordField Demo Program.OK_JButton"));
waitFor("object.exists(':Message.Congratulations! You entered correct password._JLabel')", 20000);
test.compare(findObject(":Message.Congratulations! You entered correct password._JLabel").text, "Congratulations! You entered correct password.");
clickButton(waitForObject(":Message.OK_JButton"));
}
You can also provide input for use in a script, mask* the input from the screen if it’s a password, however, the data is not masked when used in the script (meaning, it becomes a variable value). See lines 6, 9 and 11. Also common is using testInteraction.input() when the information inputted is not a password (testInteraction.password is new in 6.0).
function main() {
startApplication("SwingJPasswordFieldDemo.jar");
clickButton(waitForObject(":Swing JPasswordField Demo Program.OK_JButton"));
waitFor("object.exists(':Message.Wrong password!_JLabel')", 20000);
test.compare(findObject(":Message.Wrong password!_JLabel").text, "Wrong password!");
password = testInteraction.password("Please enter the password");
clickButton(waitForObject(":Message.OK_JButton"));
mouseClick(waitForObject(":Swing JPasswordField Demo Program.Enter password:_JPasswordField"), 35, 2, 0, Button.Button1);
type(waitForObject(":Swing JPasswordField Demo Program.Enter password:_JPasswordField"), password);
mouseClick(waitForObject(":Swing JPasswordField Demo Program.Confirm password:_JPasswordField"), 40, 3, 0, Button.Button1);
type(waitForObject(":Swing JPasswordField Demo Program.Confirm password:_JPasswordField"), password);
clickButton(waitForObject(":Swing JPasswordField Demo Program.OK_JButton"));
waitFor("object.exists(':Message.OK_JButton')", 20000);
test.compare(findObject(":Message.OK_JButton").text, "OK");
waitFor("object.exists(':Message.Congratulations! You entered correct password._JLabel')", 20000);
test.compare(findObject(":Message.Congratulations! You entered correct password._JLabel").text, "Congratulations! You entered correct password.");
clickButton(waitForObject(":Message.OK_JButton"));
}
You can also create tests which will continue without the manual input, although you’ll want to consider if it’s possible to continue for each scenario. The following scenario allows the script to continue, but it will always fail on the next step, as the manual input is required to proceed. See lines 7 through 12.
function main() {
startApplication("SwingJPasswordFieldDemo.jar");
clickButton(waitForObject(":Swing JPasswordField Demo Program.OK_JButton"));
waitFor("object.exists(':Message.Wrong password!_JLabel')", 20000);
test.compare(findObject(":Message.Wrong password!_JLabel").text, "Wrong password!");
clickButton(waitForObject(":Message.OK_JButton"));
if (testInteraction.isAvailable()){
testInteraction.information("Please enter the password and click OK on this dialog to continue.");
}else{
test.warning("This script requires the \-\-interactive option when run from the command line.");
test.log("Trying to proceed with test without manual input");
}
clickButton(waitForObject(":Swing JPasswordField Demo Program.OK_JButton"));
waitFor("object.exists(':Message.Congratulations! You entered correct password._JLabel')", 20000);
test.compare(findObject(":Message.Congratulations! You entered correct password._JLabel").text, "Congratulations! You entered correct password.");
clickButton(waitForObject(":Message.OK_JButton"));
}
More examples are available here including: