Testing is a good thing.
The problem is that there isn’t enough of it going on in the Flex community. It is still the exception to find a client who is considering writing tests early in the process.
One day while I was trying to figure out how to convince a client that they need to write tests right now, I realized I am a hypocrite. After all, the majority of my own projects, internal tools, and even components had minimal automated testing.
I tried rationalizing this and always came back to the same conclusion. Most of the work I do is UIComponent based or component framework based. Most of it has an element of asynchronicity. Most of it didn’t work very well with the standard tool for testing Flex, FlexUnit.
To be fair, there is another major way to test Flex, functional testing with the automation framework and Mercury QTP. It is actually a great tool, but it too has some limitations and, frankly, is an expensive barrier to surpass. Flex 3 has addressed some of these issues with new licensing, but using QTP currently requires a major investment in tools and technology. I can, and have, argued that this is still worth while for organizations with large Flex projects, but a community of individual developers is not going to buy into this for their own projects.
That’s what started a few months worth of weekend work to provide something that could go further into the UIComponent (and Cairngorm) testing space. To provide a framework that could follow tests like this without a prohibitive amount of effort:
Instantiate a form with a few controls, some validators and a submit button that broadcasts an event.
Provide the data to the form
Check to ensure the validator events fire at the appropriate time.
Simulate the button click
Verify that the event that was broadcast contains the correct data
Create a new component
Set the dataprovider
Add an item to the dataprovider
Check that the new item could now be selected
I needed this level of integration if I was to realistically test even the majority of cases that I cared about. I tried doing this with FlexUnit, but ran into a lot of issues with the asynchronous handling, and, frankly, FlexUnit was designed to do unit tests and I was unfairly pushing that envelope.
So… I’d like to introduce the beta of the dpUInt project. It is a googlecode project where we have published the testing framework used internally at Digital Primates.
The core testing code works very well, but it has always been a tool used internally, so, before now, we never took the steps to solidify it as a product. We have a laundry list of features still to add and more content and documentation to write about the smooth integration with Ant, AIR and CruiseControl. We hope to flesh a lot of that out over the coming weeks, but invite those that are interested to read the documentation online and see if this is a framework that might help eliminate the reasons you aren’t testing.