View Full Version : How i can test GXT application by siesta tool

Nisreen Mardawi
19 Dec 2011, 6:41 AM
Hello Admin

I have GWT EXT (GXT) application , how i can use siesta tool?

Thank You

19 Dec 2011, 9:20 AM
You need to ask the author... usually on his own site.

19 Dec 2011, 9:25 AM

Well, GXT assumes that your application is written in Java and it produces HTML/JS output after compilation. Using Siesta you can test GXT application at the lower level, as any other "plain" html page (using CSS selectors, element ids etc). You can use a generic Siesta.Test.Browser test class for that.

However you will not benefit from the higher-level ExtJS assertions, which operates on JavaScript objects (and provided in Siesta.Test.ExtJS class)

For getting started guide please refer to: http://bryntum.com/products/siesta/docs/#!/guide/siesta_getting_started (http://bryntum.com/products/siesta/docs/#%21/guide/siesta_getting_started)

8 Apr 2013, 4:43 AM
Hi All,

Can any once suggest a testing tool(Automated or Manual testing for Sencha GXT 3.0.X applications?

Colin Alworth
13 Apr 2013, 1:00 PM
I just gave a quick talk on the (very first) monthly GWT Community Hangout about a new tool I've started to help build maintainable automated tests. It uses WebDriver/Selenium to talk to the browser, and requires a small addition to your application to make it testable, but other than that, you shouldn't need to customize your application much to make it testable.

This is still very much a work in progress - I don't have any public jar files yet because I'm still working on the API, but would welcome any criticism/code review/use cases that you might have to offer. The docs are pretty scarce too - the talk I gave was my first try at opening this up to the world, but I'm continuing to work on this as time permits.

To my knowledge, this is the first GWT browser testing tool out there that deals with the problem in a comprehensive way (i.e. not assigning so-called debug ids, or using css class names to suggest structure in the app).

The basic premise is that you shouldn't structure your tests based on the dom that the app builds, but based on the ui that the user interacts with - phrases like "find the panel with heading 'Create a Company'", then "in that panel, find the field with the label 'Company Owner'" should be easy to write, and not dependent on html structure or exactly how you compose presenters/RPC/stores in your app. Some things will need to be a bit specific (Grid and ListView are not interchangable, and have different ideas in how you interact with them), but some are (most fields can be thought of as just text inputs you can type in).

Link to the hangout video - my talk starts around 24 minutes in and lasts about 10-15 minutes:
If there is interest, I'll keep writing about this and putting together more documentation/hangouts.

Sample app:
This project only has a handful of commits that build from a simple app to having a few tests that fail, and finally to fleshing out the app slightly to make those tests pass.

GWT-Driver, the main inner workings that bind WebDriver and GWT Widgets:

GXT-Driver, a library specific to GXT 3, adding support for a few main pieces of functionality. So far it is just forms, windows, and a bit of menus, but grids are slowly on the way:

As said in the talk, you can find me most days on freenode in ##gwt and #extgwt if you'd like to chat more about this topic and help keep this project going.