Continuous Integration mit FlexUnit und TeamCity

10 Kommentare

Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily – leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly. This article is a quick overview of Continuous Integration summarizing the technique and its current usage. – Martin Fowler

Although there are several unit testing frameworks available for flex applications, with FlexUnit probably beeing the most prominent, running testcases with those frameworks still remains a manual task. Since unit tests are written in actionscript as well they need to be executed within the Flash Player and therefor only give visual feedback whether the tests succeed or fail.

This is not satisfying in automated software testing environments, but due to security restrictions the Flash Player offers limited means to interact with the host system and report the test results. Peter Martin wrote an Ant test runner for FlexUnit that overcomes this limitation. The test results are reported to the test runner over a local network connection, and the test runner outputs them as JUnit reports which can then be postprocessed by the conventional JUnit Ant tasks.

We here at Catalysts use TeamCity for continuous integration and hence are spoiled by the notification and reporting possibilities we know from its built-in JUnit test runner. After some digging in the TeamCity manual we found out that it is easily possible to write a custom test runner that can report results in a way that is understood by TeamCity. Stuffed with this knowledge and one espresso later we had our own patched version of FlexAntTasks that is able to talk to TeamCity. Peter promised to integrate that into his codebase and might provide it with the next release.

In the meanwhile the patched sources and binaries can be downloaded here:

Vorheriger Beitrag
EJB 3.0 Annotations mit Hibernate Lazy Loading
Nächster Beitrag
1. Wispri: Erfolgschancen steigern, Risiken senken

Related Posts

Resourcebundles mit Ant automatisch auf Konsistenz prüfen

, ,
2 Kommentare

ResourceBundles werden in verschiedenen Programmiersprachen (Java, Adobe ActionScript,…) benutzt, um Anwendungen zu internationalisieren. Man erstellt für jede Sprache, in der die Anwendung später übersetzt werden soll eine Datei, in der dann die übersetzten Zeichenketten in der jeweiligen Sprache eingetragen sind. Dieser Blogeintrag zeigt, wie man ResourceBundles mit ANT automatisch Überprüfen kann.


10 Kommentare. Hinterlasse eine Antwort

Hello, is it possible to have TeamCity automate Flex/AS3 building as well? Not just Unit Testing? I use Tofino, a free Visual Studio Flash Plugin (Awesome by the way). I use TeamCity for .Net as of today, but want to use it for Flash building too.



Thank you for writing the support for TeamCity!

BTW, the task can automatically determine that it is run within TeamCity build by the presence of teamcity.version Ant property or TEAMCITY_VERSION environment variable. This way the patch will be non intrusive for builds run out of TeamCity and can be enabled automatically within TeamCity.

Also, the code might need to escape ‘, n, r, | and ] symbols by “|”, as explained in the TeamCity doc ( )


    @Yegor: Thanks for your feedback, I’ll put that on my list of planned improvements. Actually I’m looking forward to have Peter Martin integrate those changes or put it on sourceforge or the like, I don’t want to maintain a second codebase here.


Sorry for my bad english…
I tried to use patched flexunit.jar, but received error:

C:devprojects2video-commonbuild.xml:12: taskdef A class needed by class cannot be found: org/dom4j/DocumentException


I’m not picking on you, but I find it absolutely bizarre that many Flex related enhancements are posted to blog posts as .zip file attachments instead of creating a proper version controlled, open source project. Google Code and Assembla are free, as well as other version control/project hosts. It would be much more palatable to use this fork if it were a real project and not just a blog post. That way I could actually submit a defect and a fix if I found any issues.

This is the 3rd time this week I’ve had a blog post with a .zip attachment and all three were related to Adobe products. I’m beginning to suspect that it’s a cultural issue with the community.


    I would have made it an open source project if it were my codebase. My contribution is just a patch to someone else’s code that i can harldy put on Google Code, Sourceforge, or the like without consent. Hence the zip file was my only option to make it available to the public.


You can trigger flex builds in a variety of ways by using mxmlc/compc. These are .exes so can be run from the command line. With Java projects the most common methods would be via Ant (mxmlc task) or Maven (via flex-mojos).


Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Bitte füllen Sie dieses Feld aus
Bitte füllen Sie dieses Feld aus
Bitte gib eine gültige E-Mail-Adresse ein.
Sie müssen den Bedingungen zustimmen, um fortzufahren