Skip to content

Case study: moving from stone age TestComplete Flex GUI automation to Flex UI Selenium

October 18, 2015

It happened that on one of our company projects we needed to support legacy GUI, coded using stone age Flex, version 3.5(current version of Apache Flex is 4.14.1). So after few meetings we decided to change testing tool from unstable and slow TestComplete executions to Selenium.

TestComplete tests were used for two main things:

  1. To prepare and configure servers for further functional testing of another system component(configuration routine consists of interaction with SOAP web services, PostgreSQL BD injections, replacements in xml and properties files, copying files and etc.).
  2. GUI acceptance tests(End-to-end test, acceptance use cases automation).

Previous project team faced problem to automate GUI acceptance tests on early development phases. Due to poor expertise it was decided to use TestComplete tool to automate acceptance test and configuration routine(copy configuration files, restart services, make substitutions in existent properties files and etc.). But later on when code base enormously increased up to 25K lines it became difficult to maintain. It became unstable, took a lot of time to execute and eventually caused only problems instead of valuable feedback about project quality and product quality itself(actually 3-4 years of test development).

To get rid of all mess up in code base it was decided to refactor code and apply PageObject pattern to all TestComplete GUI tests. Code became more clear and stable. But still it took too long to execute tests that led to increased feedback time to development team. After refactoring it became possible to split bulky project into two logically independent parts. First for servers configuration routines and second for GUI acceptance tests. Devision helped to move configuration project from TestComplete test cases to Java based project that reduced configuration time in 3-4 times (from 1 hours 15 mins to 20 mins) and became more stable.

But we still got unstable and slowly executed TestComplete tests that need to interact with web browser. After some research we found some good libraries from Google such as sfapi and flex ui selenium. It’s pretty old (development stopped in 2010) but wiki has all proper information to get started. It allowed us to use all power of Selenium webdriver in GUI automation(PageObject and PageFactory patterns and so on).

As a conclusion it took about 1 year to understand and get rid of improper approach in test automation. Choose right tools and learn on other’s experience to avoid emergencies in production.

Useful links:


Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: