Squish tip of the week: How to determine if a checkbox is checked?

You can check the state of a checkbox, radio button, or the property of any other object or widget using Squish.

Using a test.compare() Verification Point

The line below looks at the object :Controls.My_CheckBox and indicates if the verification point passed or failed: passed if the checkbox is checked, and failed if the checkbox isn’t checked:

test.compare(findObject(":Controls.My_CheckBox").checked, True)


Squish tip of the week: Enable Verbose Test Result Logging

Need more detailed information in your test results?

Nightly or scheduled test runs results often provide valuable quick-read information.

What about times when verbose logging, or a Test Audit Log, may prove valuable?

The following example illustrates how to create a fully-customizable Test Audit Log using Squish. Each action is modified to include a log message and description when executed. Simply calling the enableVerboseLogging() function from the main() test case activates verbose logging.

Functionality available for all Squish-supported scripting languages and application toolkits. Example in Python using Java Swing application.


def main():
# activate item
def alterActivateItem(activateItemFunction):      
    def wrappedFunction(menuObject, 
                       logText="activateItem() called"):
       test.log(logText, 'Activated item %s' % objectMap.
    return wrappedFunction

# click button   
def alterClickButton(clickButtonFunction):       
    def wrappedFunction(button, logText="clickButton()"
                        + " called"):    
        test.log(logText, 'Clicked %s' % objectMap.
    return wrappedFunction
# mouse click 
def alterMouseClick(mouseClickFunction):   
    def wrappedFunction(objectToClick, posX=None, 
                   posY=None, buttonClicks=None, 
                   buttonState=None, buttonPressed=None,
                   logText="mouseClick() called"): 
        test.log(logText,'Mouse clicked %s' % objectMap.
    return wrappedFunction

# type
def alterTypeFunction(typeFunction):
    def wrappedFunction(objectToTypeIn, stringInput,
                        logText="type() called"):
        test.log(logText, 'Typed %(text)s in %(field)s'
                 % {"text":stringInput, 
        typeFunction(objectToTypeIn, stringInput)
    return wrappedFunction

# call Squish function modifications
def enableVerboseLogging():
    test.log("Verbose logging enabled")
    global activateItem
    activateItem = alterActivateItem(activateItem)
    global clickButton
    clickButton = alterClickButton(clickButton)
    global mouseClick
    mouseClick = alterMouseClick(mouseClick)
    global type
    type = alterTypeFunction(type)


Yet another static code analyzer run

Looking for the answer to a 64-bit build question I ran into a news item titled “The Unicorn Getting Interested in KDE“. Since I never saw an unicorn before this made me curious.

Turns out that a company selling a static code analysis tool has been analysing KDE code. This is not the first time some provides such feedback to Open Source projects. Did this

My favourite finding is this redundant if() statement:

if ( type == "String" ) t += defaultValue; //<==
else t+= defaultValue; //<==

Can anyone tell how old the KDE code base is? And did they approach anyone from the project, yet? The posting is just two days old but it might already be old news in todays age...

Measuring QML Coverage

Last year we started receiving the first requests for QML coverage. “Sure. We’ll look into it.”, we replied. It seemed like a logical extension of our cross-language coverage tool Squish Coco. At least on first sight.

At this year’s Qt Contributors’ Summit the question came up independently in one of the sessions. I had nothing to show back then. But now, there’s finally a prototype accomplishing a proof of concept. To be seen live in action at froglogic’s Qt Developer Days 2014 booth.



Squish tip of the week: How to Write Test Data to a File in 3 Simple Steps

Test results have value beyond basic reports; Why not share the data?

Write test-related information (or pretty much anything) to an external file:


Squish tip of the week: How to test Web Apps on Mobile Devices

Did you know that you can test web applications on mobile device or tablet browsers as well as desktop browsers?

With the Squish for Web edition installed on a desktop machine:
  1. Configure Squish to use standalone proxy server listening on a port (let’s say 8001) by executing the following command from your Squish install directory:
    $ ./bin/squishserver --config setProxyConnectAddress localhost:8001
  2. Start an HTTP-Proxy server (using a different port number, let’s say 8044) on the same computer by executing the following command from your Squish install directory:
    $ ./bin/webproxy/proxy -H PC_NAME_OR_IP -p 8044 localhost 8001
  3. Connect your mobile device or tablet to the same network as your desktop computer
  4. Open the device’s Wi-Fi settings and edit your currently connected Wi-Fi network settings (iOS – click the i for more info, and in the HTTP PROXY section click Manual; Android – tap and hold the currently connected Wi-Fi network, click Modify network and check the Show advanced options check box)
  5. Enter your desktop computer’s IP address or name in the Proxy hostname or Server box, and enter the HTTP-Proxy port (in this example 8044) in the Proxy Port or Port box
  6. Save and close the settings area on your device
  7. To test your connection, open a browser on your device and navigate to http://www.froglogic.com/startsquish/ (or any link followed by /startsquish). The browser page should load a Squish/Web Automated GuiTesting page with a Waiting for start of next testcase… status
  8. Open the Squish (for Web) IDE and select Edit > Server Settings > Browser, and choose the Browser on Mobile Device option.
Squish is now configured to test Web applications on your device!