Right now the FlexUnit team is quite small and 120% of our time is occupied with development and user support. Unfortunately this means that the best engineered plans for good documentation seem to get farther behind as the days go on.

We are looking for a few people who would be willing to own large chunks of the documentation. We would arrange conference calls as needed with the developers of key sections to talk through approach, technical details and future plans. The goal would be to ensure you have a full understanding and access to anyone you need when writing. Ultimately, it would also give you a few things.

First, you would have unlimited access to learn FlexUnit at a very, very deep level. Second, you could help create a volume of work (I am hoping we can produce both wiki content and eventually a comprehensive PDF book) which will continue to be attributed to you. Third, that attribution plus future recommendations from myself and others on the team and in this industry are guaranteed (and very helpful for future interviews).

Anyone who is seriously interested should leave a comment on this post and I will reach out to you immediately.

If you want to take a look at our current efforts, head over to docs.flexunit.org

Thanks,
Labriola

Parameterized Testing

Constructor (JUnit Style):

Method (TestNG Style):

External Data for Parameterized Testing and Theories

Rules Implementation

Directory Scanning and Test Loading

Performance Improvements

UIImpersonator for AS or Flex

Asynchronous Functionality now Available in Parameterized Testing and Theories

Package level assertions

Timing information during test run

• Flash Professional CS (3-5)
• Flash Builder 4 or
• Flex Unit 4 source and can compile the ActionScript only version of the Flex Unit 4 SWC.

Definitions: In Flash Builder 4 there is a new project type called a Flash Professional Project. In Flash Creative Suite there also is something called a Flash Project. They are not the same thing, and for the sake of clarity I will be referencing these two things as: FB: Flash Project and FCS: Flash Project. Flash Builder 4: The Unfortunate Truth One of the new features in Flash Builder 4 is not only Flex Unit 4 but the ability to a have Flash Professional Project with round trip development support, features and debugging. From a development standpoint that is pretty great for those of you who are not Flex developers and want to use Flash Builder as a AS development tool for our Flash CS project. While I’m not going to talk about everything that entails, my initial hope was that with this new project type in Flash Builder 4 I could run Flex Unit 4 against the FB4: Flash Project the same way you would run Flex Unit tests against a Flex/AS Project. Unfortunately this is not the case from Flash Builder. When attempting to launch your Flex Unit tests against a FB4:Flash Projects you will get several errors basically because Flash Builder is not actually compiling your application, Flash CS is, and Flash Builder does not know how to compile the Flex Unit tests into your FB: Flash Professional project. The FB4 IDE is slightly misleading in this regard, as it actually allows you to create and attempt to run the Flex Unit tests against your FB: Flash Project. Until this is supported should probably be disabled in Flash Builder 4 for Flash Professional Projects. Hopefully the Flash Builder and Flash CS teams can get this ironed out and working in the future. You can however create a new project that would just be for testing the ActionScript in your Flash CS project. You won’t be able to test anything that is working with items in the Library, and will have to be mindful of anywhere you are doing Library Linking MovieClip/Code Behind but you could approach your project that way. Flash Professional: Our Only Hope (For Now) In the meantime, if we want to test everything in Flash CS project including using library assets this leaves us with only one option, import the flex unit swc’s into Flash CS and run the tests from the Flash CS IDE. This is not as pretty of a workflow since it requires a few extra steps and some cleanup. For the time being let start from the top and work through the steps to get Flash CS working with Flex Unit 4. Don’t forget that at some point you may also need to remove the Flex Unit SWC and make your project normal again prior to deploying your Flash application excluding the tests from your deployment files. There are three ways of adding the SWC in Flash CS, the first is the old way of adding the necessary SWC to the properties on the FLA. The second is from the projects panel, where you can add SWC to your project there instead of directly on the FLA. The third way is adding the SWC to Flash CS Preferences via : Preferences > ActionScript 3.0 Settings. In this example I will be added to the FLA. Step 1: Add the correct SWC to the FLA or Project properties. Since Flex Unit 4 can be used for Flex projects and ActionScript 3 projects, there are two Flex Unit 4 SWC’s that are shipped with Flash Builder 4. We are not working with MXML so we need to make sure to get the ActionScript only Flex Unit 4 SWC. For a standard install on windows, you can find this SWC here: C:/Program Files/Adobe/Adobe Flash Builder 4/plugins/com.adobe.flexbuilder.flexunit_4.0.0.272416/flexunitframework/libs/version3libs/ASProject/flexunit-core-as3-4.0.0.4-sdk3.5.0.12683.swc Open up the Publish Settings for your FLA and add the SWC to the ActionScript 3.0 Settings. Step 2: Retaining MetaData Tags The next thing we need to do is make sure Flash CS does not strip out the metadata tags that we will need when working with Flex Unit 4. By default, Flash CS will remove MetaData tags at compile time. Currently there is no built in support in Flash CS to add compile time arguments like in Flash Builder. Oddly enough, if you configure the FLA to generate a SWC, it will keep the MetaData tags intact. On the Publish Settings for the FLA, make sure that “Export SWC” is checked. Step 3: Start working with Flex Unit 4 Now that we have the Flex Unit SWC and MetaData tags are being retained, we can start working with Flex Unit. To use Flex Unit, we need 4 things:

1. Flex Unit UI : The HUD for Flex Unit to output our results to.
2. UI Listener: The object that will be relaying information from the FlexUnitCore to the UI
3. Initialize the FlexUnitCore
4. Create some tests, and execute them.

Step 4: The Flex Unit UI Flash Builder 4 provides a AS3 version user interface displaying the number of tests that passed / failed. Unfortunately, the “AS3 UI Runner” included with Flash Builder 4 actually was built using Flex. So if we wanted to use that one, we would need to add the necessary flex SWC’s to our project as well. Since I do not want the Flex Framework anywhere near my project for someone to accidentally program against, in this example I will opt not to do that.

1. Create a new Class that extends MovieClip
2. Implement the IRunListener interface Location: org.flexunit.runner.IRunListener
3. Implement the appropriate methods: testRunStarted, testStarted, testFinished, testFailure, testAssumptionFailure, testIgnored
4. Add any UI stuff to look at.
5. Example just uses trace statements.
6. See example file in the zip: FlexUnitDemoUI.as

Step 5: The UIListener Next we also need a UI Listener to go with our UIRunner, this will be the object delegating events from the core into the Listener. A simple example of this is included in the zip file. Step 6: Initialize FlexUnitCore The last setup item we need to do is initialize the FlexUnitCore, and add a Listener: UIListener, that has a reference to the Flex Unit UI. Step 7: Build Tests and Run Them Everything else is just like how we would do things in Flash Builder with Flex/AS only projects. Build your tests and run them by calling core.run( Test, Suite, etc.); Other: If you’d like to use the Hamcrest tests, feel free to add this SWC as well. C:/Program Files/Adobe/Adobe Flash Builder 4/plugins/com.adobe.flexbuilder.flexunit_4.0.0.272416/flexunitframework/libs/version3libs/Common/hamcrest-1.0.2.swc That wraps things up. Included below is a test project of this. You will need to have Flash Builder 4 installed, and you might need to update the swc path if your install is located in a different location depending on your operating system. Happy unit testing. Ben Schmidtke Download

So, if you are planning to head to Max, and you are interested in TDD, try to attend. I think it will be well worth the effort.

That said, there will also be two sessions at the 360|Flex Max unconference where we will be reviewing the FlexUnit 4 framework from the inside out. The goal here is to provide initial context for those interested in becoming committers on the project. FlexUnit 4 is a highly functional testing framework, but it is also complex. Until we have the chance to document every corner, this might be your best chance to learn the ins and outs of it.

Finally, working on this session has given me the opportunity to work with the FlexUnit plugin in Flash Builder. I must say I am very pleased with how this is evolving. Nonetheless, there are a few enhancements I would still like. If you are of a like mind, read through the bugs and cast your vote.

• Auto Refresh of the flex unit compiler application when deleting a test case or (minimally) re-running the wizard
  Right now deleting a test case causes a manualy compilation error that needs resolution. I think this could be more elegant.
• Uncheck Create Constructor by default in FU4 test case
  Just a minor inconvenience. You generally don’t need constructors in FU4 test cases, so you uncheck a checkbox… often
• Generate Before/After in place of setup/teardown for FU4 testcases
  Right now the wizards don’t know how to generate the FU4 equivalent of setUp() and tearDown(). Not a big deal, but I think it’s low-hanging fruit.
• Remember Last Selected Type when creating test cases from the wizard
  Just a minor inconvenience. You always need to re-select the radio button when using the wizard with FU4.

If you have tried either of these and want to discuss, or if you haven’t had the time and want to learn more first, please come and support one of the following great events where I will be presenting.

September 5th, Rimini, Italy at Flash Camp on the Beach

Testing with Flex and Flash Builder

5th – Test Driven Development with Flash Builder
5th – Creating Custom Components in Flex 4
5th – Book Signing and Meet the Authors Event

6th – Creating Custom Components in Flex 4
6th – Battle of the Flex Frameworks Panel

7th – Creating Custom Components in Flex 4- Twice

Also, in the next couple of days we will be announcing the details of a special event on the 6th and 7th in coordination with the 360|Max unconference for individuals interested in becoming contributors to the FlexUnit 4 project.

15th – From Concept to Concrete: Programming a Designer’s Vision
16th – Reanimating Dead Data with Flex

Next Generation Testing

I hope you have the opportunity to participate and engage with the Flex community at some of these community events.

Cheers,
Mike

There are a huge number of fixes and enhancements in this version, all of which you can find for yourself on the release notes page but the largest change of note is the availability of CI tasks and a CI listener to allow easy hooks into the continuous integration system of your choice. A lot of hard work went into building and vetting these out on different platforms but I wanted to call out a few names in particular.

First, thanks to Peter Martin, because all of this was based on his original work for the FlexUnit .9 tasks. Second, thanks to Joe Adkins, Conrad Winchester, Brian LeGros, Xavi Beumala and Simeon Bateman all of who contributed to development, testing and/or generally being good spirits despite inevitable development slow-downs and hiccups. This is beta code, so there are a couple of caveats and to-do items still on the list, so please be sure to check out the README file in the sample project, or read it on the wiki.

So, take a few minutes, grab the bits and play around. If you have any questions or comments, in particular around the new CI tasks, head over to the FlexUnit forums. If you believe we mutually disagree on the definition of a functional feature, then please log it into the bug database.

This is a completely community run project and your help and support are always welcome.

So, first a little background. FlexUnit 4 is the name for an upcoming release of FlexUnit. It represents the best features of the FlexUnit project combined with the best features of the Fluint project. It is built on top of a newly created foundation designed to support the latest techniques used in the JUnit testing community, but written for the specific requirements and needs of the Flash Player. Top all that off with an extensibility layer that encourages developers to create new types of test runners and extensions while simplify the process of integrating the results into IDEs and continuous integration environments, and it should give you an idea why I am excited about this release.

If it sounds interesting to you as well, the public alpha of this upcoming release is now available as a turnkey test project you can download from the adobe open source site. I hope you will use it to learn and explore the new features, and to provide feedback about any bugs you find along the way. However, it is an alpha, so locations and names of classes, signatures of methods and even which features are supported are all subject to change before release. It is not be advisable to use this as your production testing system.

Speaking of features, let’s jump in. There is a bit more content to go through than the original 60 second tutorial, so, I think you will need 4-6 minutes to get through it all. To keep things consistent, many of these examples are adapted right from the JUnit in 60 seconds site referenced above.

1. Test Metadata
   Test cases are now marked with a piece of metadata named [Test]. Your tests no longer need any special name (prefixed with test, etc.) Also, the need for specific Test and Suite classes disappears. Your classes no longer need to inherit from any framework class. Here are a couple of sample tests. [Test] public function addition():void { Assert.assertEquals(12, simpleMath.add(7, 5)); } [Test] public function subtraction():void { Assert.assertEquals(9, simpleMath.subtract(12, 3)); }
   Because your test classes no longer inherit from a class in the FlexUnit framework, you will notice that the assert functions you used in the past (assertEquals, assertTrue) are now referenced as static functions of the Assert class; more on the new ways of asserting later in this post.
   
   
2. Before and After
   Sometimes you need to setup your test environment (or fixture) for your tests. In the example above, you need to ensure your simpleMath reference exists before the tests are run. In previous versions of FlexUnit and Fluint you could override a setup() or teardown() method to accomplish this goal. FlexUnit 4 introduces Before and After metadata which accomplishes a similar goal. Any methods marked with Before will be run before each test method. Any methods marked with After will be run after each test method. This also means you can have multiple methods that run before or after the test.
   
   [Before] public function runBeforeEveryTest():void { simpleMath = new SimpleMath(); } [Before] public function alsoRunBeforeEveryTest():void { simpleMath1 = new SimpleMath(); } [After] public function runAfterEveryTest():void { simpleMath = null; simpleMath1 = null; }
   If you do choose to use multiple before or after, you can control the order that these methods execute using an order parameter. So, for example [Before(order=1)], [Before(order=2)].
   
   
3. BeforeClass and AfterClass
   Methods marked with Before and After will run before and after each test method respectively. BeforeClass and AfterClass allow you to define static methods that will run once before and after the entire test class. Like Before and After, you can define multiple methods for BeforeClass and AfterClass and can control the order. [BeforeClass] public static function runBeforeClass():void { // run for one time before all test cases } [AfterClass] public static function runAfterClass():void { // run for one time after all test cases }
4. Exception Handling
   Test metadata can also have an expects parameter. The expects parameter allows you to indicate that a given test is expected to throw an exception. If the test throws the named exception it is considered a success, if it does not, it is considered a failure. This prevents us from having to write tests wrapped in a try block with an empty catch. [Test(expects="flash.errors.IOError")] public function doIOError():void { //a test which causes an IOError } Or
   [Test(expects="TypeError")] public function divisionWithException():void { simpleMath.divide( 11, 0 ); }
5. Ignore
   Ignore metadata can be added before any test case you want to ignore. You can also add a string which indicates why you are ignoring the test. Unlike commenting out a test, these tests will still appear in the output reminding you to fix and/or complete these methods. [Ignore("Not Ready to Run")] [Test] public function multiplication():void { Assert.assertEquals(15, simpleMath.multiply(3, 5)); }
6. Async
   In previous versions of FlexUnit it was difficult to have multiple asynchronous events and to test code that was event driven but not always asynchronous. Fluint provides enhanced asynchronous support including asynchronous setup and teardown, but every test carried the overhead of the asynchronous code to facilitate this feature. FlexUnit 4 allows the developer to specify which tests need asynchronous support using the async parameter. When provided, the async parameter enables the full asynchronous support provided by Fluint for that particular test. When the async parameter is specified you may also specify an optional timeout for the method. [Before(async,timeout="250")] public function setMeUp():void { } [After(async,timeout="250")] public function allDone():void { } [Test(async,timeout="500")] public function doSomethingAsynchronous():void { //Async.proceedOnEvent( testCase, target, eventName ); //Async.failOnEvent( testCase, target, eventName ); //Async.handleEvent( testCase, target, eventName, eventHandler ); //Async.asyncHandler( testCase, eventHandler ); //Async.asyncResponder( testCase, responder ); }
   In addition to the async parameter, there are several new Async methods, each of which can also take individual timeouts, handlers and passThroughData.
   
   
7. Hamcrest
   Earlier I alluded to new assertions. Thanks to the hamcrest-as3 project we now have the power of Hamcrest assertions. Hamcrest is based on the idea of matchers which match conditions for your assertions. For example:
   
   [Test] public function testGreaterThan():void { assertThat( 11, greaterThan(3) ); } [Test] public function isItInHere():void { var someArray:Array = [ 'a', 'b', 'c', 'd', 'e', 'f' ]; assertThat( someArray, hasItems("b", "c") ); }
   For more information on hamcrest:
   • Hamcrest AS3
   • Hamcrest
   • Hamcrest Tutorial for Java
   • Hamcrest Tutorial for PHP
   
   
   
8. Suites
   FlexUnit 4 has a concept of test suites just like FlexUnit and Fluint. Test suites are just a collection of classes that represent tests or even other suites. A suite is defined by the [Suite] metadata. However, in FlexUnit 4, you also need to provide one additional piece of metadata called [RunWith] which instructs the test runner to execute the tests defined below using a specific class. The [RunWith] metadata forms the basis of the extensibility layer which will be discussed shortly.
   
   [Suite] [RunWith("org.flexunit.runners.Suite")] public class FlexUnitIn360 { public var t1:BasicMathTest; public var t2:MyTheory; }
   The test cases and any nested test suites, are simply defined as public variables. There is no need to instantiate them or mark them in any other way. FlexUnit’s test suite code understands how to recursively parse this class and find the tests.
   
   
9. User Defined Metadata Parameters
   It’s often extremely useful to include additional pieces of information which are relevant to your development process when defining tests. So, for example, you might want to provide a detailed description of what a test is supposed to prove. This description could then be displayed if the test fails. Or perhaps you would like to note that a test relates to a give issue number in your bug tracking system. These custom parameters are stored by the framework when encountered during the test and can be used in reporting the success or failure later.
   
   [Test(description="This one makes sure something works",issueID="12345")] public function checkSomething():void { }
10. Theories, Datapoints and Assumptions
    This is probably the largest single new feature as it introduces a whole new way of testing. A developer can create theories, which are ‘insights’ into the way a given test should behave or over a large, potentially infinite set of values. In other words these are tests that take parameters. The parameters are defined in properties, arrays or can be retrieved from functions or other external sources. A complete description of this feature can and will take a lot of documentation, however, if you are up for reading a bit of theory, this document will introduce the ideas . Here is a quick sample of using these new techniques:
    
    [DataPoints] [ArrayElementType("String")] public static var stringValues:Array = ["one","two","three","four","five"]; [DataPoint] public static var values1:int = 2; [DataPoint] public static var values2:int = 4; [DataPoints] [ArrayElementType("int")] public static function provideData():Array { return [-10, 0, 2, 4, 8, 16 ]; } [Theory] public function testDivideMultiply( value1:int, value2:int ):void { assumeThat( value2, greaterThan( 0 ) ); var div:Number = simpleMath.divide( value1, value2 ); var mul:Number = simpleMath.multiply( div, value2 ); Assert.assertEquals( mul, value1 ); } [Theory] public function testStringIntCombo( value:int, stringValue:String ):void { //call some method and do something }
    In this case, there are datapoints defined by static properties as well as method calls. The framework introspects the datapoints and uses this data combined along with any type specified in the ArrayElementType metadata. This information is used in combination with the theory method signatures to call each theory for each possible combination of parameters.
    
    
11. RunWith
    FlexUnit 4 is nothing more than a set of runners combined to run a complete set of tests. A runner is a class that implements a specific interface and understands how to find, execute and report back information about any tests in a given class. Each time a new class is encountered, FlexUnit 4 works through a list of possible runners and attempts to identify the correct one to execute the tests contained in the class.
    The RunWith metadata allows you to override the default choice made by the framework and specify a different class to act as the runner. This feature allows developers to write entirely new types of runners, with support for new features, which can work directly with the existing framework and report their results back through the same interface.
    In the case of the suite, you are instructing the framework to run this class in a specialized runner that simply finds the correct runner for all of the classes it contains.
    
    [RunWith("org.flexunit.runners.Suite")]
    
    
12. Adapters
    Using the flexibility of the multiple runners discussed above, the new FlexUnit 4 framework has legacy runners built in for both FlexUnit 1 and Fluint tests. This means that FlexUnit 4 is completely backwards compatible; all existing FlexUnit and Fluint tests can be run, and even mixed into suites with FlexUnit 4 tests without any code changes.
    
    Further, supplemental runners are in development for FUnit and several other testing projects
    
    
13. User Interface Facade
    Lastly FlexUnit 4 provides a UIComponent testing facade which allows you to add or remove components from the display list. This allows you to accurately test component methods in a real runtime state. This feature creates a foundation for other projects to extend into areas of integration and functional testing without the need for extensive rewrites or modifications.
    
    [Before(async,ui)] public function setUp():void { //Create a textInput, add it to the testEnvironment. Wait until it is created, then run tests on it textInput = new TextInput(); Async.proceedOnEvent( this, textInput, FlexEvent.CREATION_COMPLETE, 200 ); UIImpersonator.addChild( textInput ); }

If you made it this far, I hope you download the alpha and start playing with it immediately. If you have significant time to devote to serious testing and debugging of the framework, contact me and I will be happy to invite you to the ongoing private beta program.

Stay tuned for some exciting news and, if you have the opportunity, be sure to make it 360|Flex for my session about the new framework. Plus, you never know, 360 is an exciting place, we may just have more to tell you by that time.

Cheers and enjoy,
Labriola

On September 26 and 27th, the folks who bring you Flex 360, put on a 2 day "Flex Camp" in New Jersery, which went over extremely well.  I was presenting on Testing with Fluint (formerly known as DPUint).  Of course, I promised my slides and materials would be up on here before the end of the weekend.  Well, realizing its over a week later, I'm finally getting them uploaded now.

So, if you were one of the many asking for those materials, here they are. 

slides
source code