• Home
• Products
• Services
• About
• Blog
• Support

Functional and UI Testing for Eclipse-based Applications

Test automation solution, handcrafted for Eclipse with revolutionary state management, ubiquitous language, modern IDE, and Maven/Tycho plugins.

Product Health Analytics and Support Automation Platform

End-user and product analytics solution that gives you rich insights into your application health, performance, and usage patterns.

Eclipse-based IDE for the Fantom Programming Language

Full-featured Integrated Development Environment for emerging Fantom programming language.

Q7

• Features
• How Q7 Works?
• Runner & Automation
• Demos
• Pricing
• Licensing
• Server

Download

Eclipse Command Language

All engineers at Xored, an Eclipse-centric company, are familiar with Java. More than 90% of the code lines we produce is still Java code. Why did we “invent” ECL and proposed it as a scripting language in Q7? To better understand rationale behind our decision to use a new scripting language as a language for Q7 and test automation in general, please read this first:
where it all started.

ECL stands for Eclipse Command Language, and it was developed and initially introduced by Xored at EclipseCon ’08 in California. ECL has its own story. It goes back to the early history of Eclipse Platform which had always experienced a lack of Scripting and Automation solutions. This problem is not related to a particular programming
(scripting) language but goes way further including an object model to script against it, data and code interoperability, and many more.

There were several projects trying to add easy scripting and automation to the platform; the most successful one was Eclipse Monkey (it was pretty dead before adopted widely). Monkey was using JavaScript as a scripting language and provided the object model (DOM) as a part of the project, which covered high level aspects of Eclipse APIs. However, we were not satisfied with Monkey’s approach either, including JavaScript used by this project.

What we did want from a Scripting-and-Automation solution is the following:

• The scripting language should be CLI-oriented, which means an end user (software engineers, testers, etc.) must be able to do virtually anything with Eclipse from a console window, for example, the same way as with the Unix shell. Here is a simple but actual ECL sample:

ecl-shell> create-project MyJavaProject -kind Java

• The scripting solution should be expressive. Our goal is to save time for software engineers and/or users, allowing to perform tasks faster then they would do with Java or JavaScript, or even using Eclipse UI. PLease review the following code:

//verify that project having "MyProject" name exists in the workspace. 
get-project | any project { project.name == "MyProject" } | true

Try to put the same code in Java using Eclipse APIs and it’ll become several lines instead of a couple.

• The scripting solution must be a general purpose instrument. End users should be able to do virtually anything with their Eclipse environment using such a solution/language. As an example:

//displays 5 installed OSGi bundles sorted by their ID in descending order.
get-bundle | sort-object -property id -top 5 -descending 

//displays all labels within "Confirmation" window sorted by label text. 
get-window "Confirmation" | get-control -type Label | sort-object -property caption

• The scripting language should be extendable and let different adopters develop their own commands, which will be interoperable with other commands (such as Unix commands, for example). Moreover, these commands and internal data structures should be also interoperable with Eclipse Frameworks.