The most tedious part of any project I find is getting the skeleton setup. Thankfully Flex Builder's project wizards make this easier. I'll be creating two Flex projects, one called GameOfLife, which will hold the UI application, and one called GameOfLifeTest, which will hold the testing code. Additionally I'll create a Java project called GameOfLifeServer which will hold the back-end code. Both the production and test code will reside in the same Java project since you can easily mix them in Eclipse's Java mode, unlike with Flex. These will all be sibling projects in a top level directory.
Command Line
First a little command line mucking to get the directories setup:
cd source/trunk/danielr/projects/
mkdir PPE
mkdir PPE/GameOfLife
mkdir PPE/GameOfLifeTest
mkdir PPE/GameOfLifeServer
GameOfLife
Run through the Eclipse new Flex Project Wizard using the directory above as the project root and accepting all the defaults.
Now onto the associated test project.
GameOfLifeTest
Run through the Eclipse new Flex Project Wizard using the directory above as the project root and accepting all the defaults.
To GameOfLifeTest I need to add the testing library I'm going to use. For this project I'm planning on sticking with FlexUnit. An alternative that I considered was fluint. Like some of my other decisions I'm sticking with what I know works well and I don't see anything with fluint that I'll be needing that FlexUnit doesn't already cover. After downloading the current release I drop it into the libs folder of the recently created project.
Next I need to put in the FlexUnit test runner scaffolding. Makes me wonder how hard it would be to extend Flex Builder to add a "Create new FlexUnit Project Wizard". In this case I'm just going to cut and paste the code from the recipe I wrote that is up on the Adobe Cookbook. Lastly I want to setup how the test project is going to reference the code from the main project. Since Flex Builder can't efficiently handle compiling multiple projects at once (i.e. a SWC library project and the application that it depends on) I'm setting this up as a source path reference. Be warned that such a setup has it's own set of problems.
Since I'm the only developer on the project I'm doing the quick and dirty "source path" add folder option. Eclipse will store a hard coded path in the project file which means that anyone else importing the project will get an error unless they also happen to store the folder at "/Users/danielr/source/trunk/danielr/projects/PPE/GameOfLife/src". The simple fix is once the project is imported, go to the project properties and update the source path folder reference.
To finish this skeleton code I want to make sure I can create and test something that exists in the referenced source path. At this point I only have the main application, but that's good enough to verify things are working with some trivial test. Note I'm break from the traditional test naming scheme since I'm going to delete this test once I have some real code to work on.
package com.neophi.gol
{
import flexunit.framework.TestCase;
import mx.core.Application;
public class ApplicationTest extends TestCase
{
public function testApplication():void
{
var gol:GameOfLife = new GameOfLife();
assertTrue(gol is Application);
}
}
}
Next I need to include it in the test suite that gets run. A quick edit to GameOfLifeTest.mxml will do the trick:
private function createTestSuite():TestSuite
{
var testSuite:TestSuite = new TestSuite();
testSuite.addTestSuite(ApplicationTest);
return testSuite;
}
Sweet. That compiles and runs and passes! Next up a small stub of the main application.
GameOfLife
Not much to do here but make sure it compiles and runs. For that I'm just going to stick in a simple label.
<mx:Label text="Game Of Life" horizontalCenter="0" verticalCenter="0"/>
That was easy enough. That is also now compiling and running. For the paranoid, you could run the test suite project again to make sure everything is still working. Remember to refresh the test project otherwise Eclipse might not pick up the fact that we changed a file in a referenced source path. Have I mentioned that source paths are buggy? Now to create a skeleton back-end. Looks like I'll work on that tomorrow as it's later than I thought.
For a snapshot of the project in process grab PPE-1.tar.gz.
Closing Thoughts
The format I used for this post is working well so I'm going to continue using it, not that you can tell all of the thought process behind it. What I've been trying is before I do something I've been writing the step down and then performing it to make sure what I thought I was going to do actually worked. Given how bad I am with tenses when writing most of the time, these posts will probably be worse in that regard so fair warning on that front. As a tongue-in-cheek expression call this approach blog first development, which some might say is a BFD.
For the history of this project see Programming Project Experiment (PPE).
Tags: flex gameoflife ppe