Skip to content

Releases: AludraTest/aludratest

AludraTest 3.0.1

26 Jun 12:11
Compare
Choose a tag to compare

First Bugfix release for 3.0.0. Fixes a serious bug in test case namings when using XML as input data format.

AludraTest 3.0.0

25 Jun 08:52
Compare
Choose a tag to compare

AludraTest 3.0.0 Release Notes

We are proud to announce the 3.0.0 Release of the AludraTest Framework!

The 3.0.0 Release marks the starting point of an AludraTest "ecosystem". Some of the new features are implemented in separate modules which can additionally be activated for your project when required. Future releases may even split up the AludraTest core into several modules, further increasing the modularity of the AludraTest architecture.

New Features

  • XML based test data, including Eclipse based Editor
  • HP ALM Connector and Service
  • CommandLine Service
  • Git Service

Changes and Fixes

  • Component Factory Pattern
  • Consistent enabled / editable Component Concept
  • Many, many Selenium related fixes and improvements

Details

XML based test data

AludraTest 3.0.0 introduces a new possible input format for Test Data. While using XLS based data is still possible, you can now also use XML files in AludraTest's own testdata format. To edit the XML files, a specialized Eclipse-based Editor has been developed, which is available as Eclipse Plug-In. See aludratest-eclipse-plugin for details.

The Eclipse Plug-In separates defining the Test Data Metadata, which in most cases is a task for the Test Developer, and entering Test Data itself, which is usually done by the Test Designer. Additionally, it integrates nicely with the Eclipse JDT (Java Development Tools) Plug-In, allowing for updating XML files automatically whenever associated Data classes change.

The XSL based format supports Excel formulas. As a replacement, the XML format supports a broad subset of JavaScript, enabling dynamic (e.g. random) test data generation and calculation.

HP ALM Connector and Service

AludraTest 3.0.0 integrates nicely with HP ALM. It can write back test execution data, including the "Test Step Groups" known from AludraTest's HTML report format as HP ALM "Test Steps", attaching Screenshots in cases of error, and even attaching HTML based details for every single Test Step. Of course, the execution status of the Test is updated as well. This way, the Test Designer using HP ALM is able to see the same degree of information without opening AludraTest's HTML report.

The connection to HP ALM is established using HP ALM's REST API.

Additionally, the REST API is wrapped into a new AludraTest Service, which now allows for testing HP ALM itself (not the GUI, but e.g. test workflows which create / modify HP ALM entities).

For more information, please see aludratest-hpalm-connector.

Command Line Service

Yet another service has been introduced with AludraTest 3.0.0: The Command Line Service, now allowing for testing and instrumenting Command Line tools, e.g. Subversion, custom scripts etc. In conjunction with the existing File Service, even more aspects of process workflows can now be tested.

Git Service

Building on top of the Command Line Service, the new Git Service allows for easy interaction with git. Most common commands are wrapped by the reliable AludraTest Service architecture, allowing for detailled test logs. Custom commands can still easily be executed.

Component Factory Pattern

AludraTest 2.7.0 introduced Plexus as its internal IoC engine. To get the most out of the advantages of a professional IoC container, it is crucial that AludraTest has control over most of the AludraTest related object creation. This is why AludraTest 3.0.0 introduces a Component Factory available on each GUI related service object. Now, you can no longer instantiate a Button or other GUI components directly, but have to call

aludraGUI.getComponentFactory().createButton(myLocator);

Consistent editable / enabled Component Concept

Previous releases of AludraTest shipped many methods like assertNotEditable(), doubleClickNotEditable() etc., performing some internal assumptions about the GUI component under test. This concept has completely been reworked and simplified. Now, every component can be click()ed or doubleClick()ed, as it can in real GUIs (but it may not respond to the click at all). A state "enabled" has been introduced, which replaces the previous, error-prone "editable" state. "Editable" now only applies to text-based input components, which can be enabled, but read-only (not editable).

Developers relying on the auto assumptions of clickNotEditable() etc. should change their code to first invoke assertNotEnabled(), then calling click() (if this is really what is desired - in most cases, clickNotEditable() HAD to be used to click something like an image).

AludraTest 2.7.0

27 Jan 16:07
Compare
Choose a tag to compare

The official AludraTest 2.7.0 release, including full (we hope) support for Selenium 1+2 and many browser engines.

Starting with today, we will work on AludraTest 3.0.0, which will contain many larger changes, also related to the API.

Bugfixes and minor enhancements will still be done based on this release. A 2.7.x branch will be created for this with the first bugfix release.

Please visit the project documentation at http://aludratest.github.io/aludratest/ for more information.