Continuous Integration with Flex – Part 1

• Tweet

• Tweet

The first step for getting your CI build up and running will be to get all your basic pieces in place on your local machine.
Some of this stuff (I hope) you will already have in place, but for the sake of being complete I’ll include it here…

1. Set up a source control repository.

Regardless of whether you do CI or not, you really should be putting your work under source control. We used Subversion because its easy to use, is free, and there are great integration plugins for windows explorer, mac OSX and eclipse. You can get information on installing subversion here

2. Install ASUnit.

So, our next step was to start using a unit testing framework. We settled on ASUnit, primarily because most of the team had already used it in other projects. I was pretty comfortable with the source, having digged into it a few times and furthermore, Luke had blogged about how one might go about CI with asunit already.
We will be playing around with the source of ASUnit later, but for now, lets check everything works as planned…

3. Create a simple Class and a test suite for it

As you create your classes, you should be creating your unit tests in parallel. Our testHarness.mxml is the entry point to our test suite, and is a pretty simple affair. All it does is instantiate our AllTests class, which basically steps through your classpath, adding tests as it finds them. ASUnit ships with a jsfl plugin to do automatically create these using the Flash IDE. As we were using Eclipse / FDT as our development platform, this wasn’t a huge amount of use to us, so Johannes rewrote the original jsfl files to run as a python script. He’s blogged about it here . Go ahead and make a couple of classes get these scripts to make the bare bones unit tests for you – its really rather clever…

4. Create a testHarness.mxml file to run your tests

So, now you have your test class created, its time to take a step back and think about how everything is going to fit together. Basically our work flow is along these lines:

1. Developer does some work.
2. Developer runs test suite locally.
3. Developer compiles build locally.
4. Developer commits code changes to the repository.
5. Build monitor checks periodically for changes to the repository. When there has been a change it:
6. Attempts to compile & run test suite. If this succeeds it:
7. Attempts to compile main build.
8. Build monitor then notifies either entire project team on successful build (hooray!) or the development team on unsuccessful build (boo).

Other than getting the developer to do some work, the tricky part of the process is actually number 6. In order for this to work, we need to do the following:

1. get our test harness to quit when all tests have completed so that our ant build can carry on and try to compile the application.
2. Get our ant build to somehow understand if the unit tests have completed successfully or not.

There are two approaches to getting the first task complete. The simplest is to get your test harness to quit after what you consider to be a safe period of time, say 30 seconds or so. In order to do this, you could just do something like this:

private function initApp():Void{
	var myTests:AllTests = new AllTests();
	setInterval(this,”onTestsComplete”,30000);
}
private function onTestsComplete(){
	fscommand(“quit”);
}

This is not ideal however, as you have to keep an eye on the length your unit tests are taking to execute – if it gets to be longer than your specified safe period, you will need to adjust the timeout period. Peter Hall ended up reworking ASUnit to an event based model such that our allTests class triggers a testComplete event when all the tests have finished running. In order to do this, he significantly changed the way that ASUnit works, so if you are looking for a simple solution, go for the option I have put in here; it’ll get you up and running…

5. Create an index.mxml file that will be used for the main build.

Now, you also need to have yourself an entry point for the application itself. So, go ahead and make one – it doesn’t matter too much right now what it is – start simple and work up. On a side note, I’d suggest you don’t launch in and try to retro-fit a suite of unit tests to a pre-existing app / codebase, unless you have a fair chunk of time on your hands, or are about to take on a hefty rework or refactor – it probably isn’t worth it…

OK – thats the end of part one. It may not seem like you’ve got very far, but you have the almost all the main elements in place for your CI suite. The next step will look at tying the pieces together by creating an ANT build that will be used to run your unit tests and compile your app