As rich Internet application (RIA) technologies are becoming more prevalent, more tools are being created to support RIA development. Flex unit test tool Fluint is an example.
InfoQ spoke with Michael Labriola, Fluint developer and Flex architect, to learn more about using Fluint as a unit test solution in Flex development. He explains:
“Fluint” is short for Flex unit and integration. It is a testing framework for developers writing Flex 2 or Flex 3 applications, regardless of whether they are deployed in the Web browser via Adobe Flash Player or on the desktop via Adobe AIR.
Fluint was originally developed as an internal tool at Digital Primates to test several very large projects. Given the growing demand for a framework like this in the Flex community, Digital Primates decided to release it as an open source project. While there are other unit test solutions for Flex development, according to Labriola, Fluint fills an important gap. He explains:
There are several other projects that do unit testing in Flex. However, Fluint is the only project to date that covers both the unit and integration levels. This is important for several reasons. Flex is a component framework. You build upon Adobe's components and make your own when you assemble an application. The problem is that a component doesn't make a very good 'unit' in the testing sense. There is a significant amount of complexity inside of those components and some aspects are inherently asynchronous.
While you will undoubtedly add methods to your application and components that will need unit tests; you will likely find that the most error-prone portion of your application is the integration of several existing components to form something new. The existing frameworks don't handle asynchronicity well. Therefore, they tend to do a very poor job of testing the integration of several asynchronous components.
Asked to provide a typical case in which Fluint may be used, Labriola responds:
This example is a little trite, but it really illustrates the power of Fluint. Imagine a simple log-in form where you have a username field, a password field and a login button. You might also have two client-side validators that ensure that the username and password are at least a character or so long, or perhaps don't contain any invalid characters. When the log-in button is pressed, it validates the two text input fields. If they are valid, it dispatches a 'login' event with the username and password so that another portion of your application can perform the login logic. If the validators fail, it displays an error message on the screen.
Any Flex 101 student should be able to write this component, but no tool other Fluint currently can test it completely.
To illustrate a few distinguishing features, Labriola pointed out the steps that make Fluint shine even in conducting a simple test such as that described in the above example:
- Add the component to the display list for testing - This step starts the internal life cycle of the components, which is needed for real testing of its methods. This is also the point at which half of the testing frameworks fail, because they don't actually allow you to add UIComponent to the display list for testing.
- Wait for the data to be committed for event testing - Large portions of existing testing frameworks do not have the ability to wait for multiple asynchronous events.
- Ensure that the component broadcasts a 'login' event and verify the username and password fields - This is the point where most testing frameworks fail to meet needs. Some simply take screen shots and do comparisons, but that won't help when the intended result is an event. Events don't appear on the screen for visual comparison. While certainly intended for a different purpose, this is also something that functional tools can't check. Functional tools generally record your actions and allow you to enter data in specific fields, but they lack the ability to catch and interrogate the resultant event.
With respect to Fluint’s development, Labriola explains:
Fluint consists of an ActionScript library, which contains the testing framework and related classes. It also has a sample test runner that is written in MXML. Those are the only two pieces that you need to write tests that run in a Web browser. However, if you are interested in integrating with an automated environment, Fluint provides a test runner
written for Adobe AIR, which will run tests compiled into separate modules and output the results into an XML file. That XML file will soon be JUnit compatible so that existing reporting tools can be used with Fluint. Finally, there is an ANT task available to make executing the AIR test runner easier.
As to further enhancements, Labriolal says:
There are a number of great enhancements proposed by the community that will likely make it into the next versions of Fluint. Right now we are working on a performance increase that will more than triple the speed of testing when working with a large number of tests by removing some inefficiency in the test runner. However, we are actively looking for contributors to the project. Digital Primates has been the major driving force so far, but we do hope that this will become a community owned project as we move forward.