Showing posts with label JUnit. Show all posts
Showing posts with label JUnit. Show all posts

Thursday, May 01, 2014

Github Public Repository Created to Illustrate Selenium WebDriver + ExtJS + JUnit

I posted a series about ExtJS testing using Selenium WebDriver and JUnit. They turned out to be pretty popular. Some reader want to see more implementation details. I committed a Github public repository with complete implementation of the core concepts described in my post. Here is the link:
Github Public RepoSJTXE(Selenium Javascript Testing eXtension for ExtJS)


By the way, you might also consider testing using Jamine and PhantomJS. They are better for blazing fast unit testing. Not quite fit for GUI testing though.

Thursday, October 10, 2013

Capture Runtime JavaScript Errors (Selenium Web Driver + JUnit + ExtJS)

In my previous post Capture ExtJS Ajax Error (Selenium Web Driver + JUnit + ExtJS), I showed how to capture Ajax errors. In this post, I'm going to show how to use similar approach to capture general Javascript errors.

First, need to inject the following Javascript code to the page under testing:
The Java code to inject the JS code above and to check runtime script error:

Wednesday, October 02, 2013

sendKeys to combobox, textbox or datefield (Selenium Web Driver + JUnit + ExtJS)

In my previous post Locate ExtJS Component (Selenium Web Driver + JUnit + ExtJS), I introduced some code snippets to find an ExtJS component using ComponentQuery. However, the elements located using that approach generally do not accept user input (except mouse click seems to work for button). Turns out ExtJS render these components using a lot of HTML markups wrapping around the real input element. The inputEl is usually the HTML element that accepts user input. So to send keys to them, a slight change is needed from the code I published in the previous post. We will need to drill down 1 level to retrieve HTML id of inputEl, and get its DOM element:

Tuesday, October 01, 2013

Capture ExtJS Ajax Error (Selenium Web Driver + JUnit + ExtJS)

Here is sample code to check ExtJS Ajax error. It's highly recommended to check this error during teardown(@After), because WebDriver won't automatically capture these problems.

First, need to inject the following JS code to the page under testing:
 Java code to inject the code and to check ExtJS Ajax error:

Monday, September 30, 2013

Examine ExtJS Store Data (Selenium Web Driver + JUnit + ExtJS)

Part of the goal of unit test is to check result against expected values using various assertions. An essential data structure in ExtJS web application is store. So, no test case is complete without some assertion against the stores. For example, we might want to verify number of records, or value of certain column, ... Here are some code samples to access store data, get number of rows, or retrieve value of a column:

Saturday, September 28, 2013

Wait for AJAX Complete (Selenium Web Driver + JUnit + ExtJS)

With AJAX, Seleinum testing can have a lot of tricky timing issue. Tests can fail due to slightly delayed AJAX response. Implicit wait solved the problem to some extent, but would be nicer to have a way to wait for all AJAX calls to be finished.

Here is a solution for ExtJS AJAX requests:
Core concept is this JS code: Ext.Ajax.requests && !_.isEmpty(Ext.Ajax.requests). It works for ExtJS 4 only, might change for future or older version of ExtJS due to how AJAX calls are managed.

Thursday, September 26, 2013

Locate ExtJS Component (Selenium Web Driver + JUnit + ExtJS)

Selenium WebDriver offers many ways to find an element. You can find it by class, name, partial link text, xpath, css selector, ... However, when it comes to ExtJS component, none of them works very well, because ExtJS page elements tend to be generated dynamically, their xpath/id/... are all moving target. Trying to figure out a repeatable way to locate any of them can be very time consuming and the result is fragile.

Fortunately, as all ExtJS developers should know, Ext.ComponentQuery provides a powerful and very reliable way to find your component. So, the idea is to use Ext ComponentQuery to find the component of interest, then pass it along to WebDriver. Along this line, below is my approach to locate components:
  • PageObject owns all the top level components, and specify a ComponentQuery that can uniquely identify them;
  • All views or components of interest have their hierarchy represented in the test code, and at each level, they should have a ComponentQuery that can unique identify each of them within the container;
  • When it's time to get the element, we should traverse up from element to page, rebuild the fully qualified component query

Ok, some sample code might explain the idea better:

Wednesday, September 25, 2013

Take Screenshot on Failure (Selenium Web Driver + JUnit + ExtJS)

First a little background: this is the first of a series of lessons I learned using Selenium Web Driver to test ExtJS web application.

It's usually desirable to always take a screenshot when test failed. The concept of JUnit rules makes this an easy task. First, implement a rule as shown below:

Then in your test classes, you just need to declare this rule, then all test methods in it will automatically take screenshot on failure.
The examples here are just for illustration purpose. In real world application, you might make some improvement like:

  • Make sure the file name is legal for the OS (for example, the following characters are not allowed in Windows file name: \/:?*<>|\
  • Pictures might be further organized into folders by test cases?
  • The rule might be declared in a base class so that all test cases have the same behavior without extra boiler plate code