How you organize project files can have a tremendous impact of the success of a project. File organization might seem unimportant, but don’t underrate how influential this factor can be. Organizing files well ensures that not only is it easier to find the files and easier for teams to work together, but also you avoid potential naming conflicts and can facilitate source code versioning (see Versioning” later in this chapter).

If you use Flex Builder to create Flex projects, you have probably already noticed that Flex Builder provides a degree of organization. Primarily, Flex Builder distinguishes between where it stores source code (.mxml and .as files) and where it stores deployable application files (.swf, .html, and runtime assets). The default names for the directories that Flex Builder uses are src for source code and bin-debug for deployable application files. This high-level structure is important and essential to good project file organization. However, you can do more, and indeed more is required to keep files organized clearly. The following are a few of the key things you can do to organize files:

Flex provides a lot of ways to apply styles to applications. You learned about all of these ways to style applications in Chapter 8. This provides a great deal of flexibility in how to style an application, which is both good and bad. It is good in that it provides lots of options. It is bad in that it allows developers and teams of developers to apply styles without a consistent approach or plan.

We find that in general, it is best to apply most, if not all, styles via external .css files. We make exceptions for some layout-related styles such as verticalAlign and horizontalAlign, which we frequently apply inline. However, we prefer to apply the vast majority of styles via external .css files. For the Flickr application, we use only one .css file because the application simply isn’t complex enough to warrant more than one .css file.

If you look at the FlickrFlex.css file, you’ll notice that we’ve organized our selectors to make them somewhat easy to locate within the file. We place the Application type selector first in the file, followed by the rest of the type selectors in alphabetical order. Then we follow the type selectors with the class selectors, also organized in alphabetical order.

Although it is sometimes tempting to apply styles via inline attributes to MXML tags, we’ve found it is far better in the long run to take the extra minute or two to apply styles via external .css. This has several advantages, some of which are as follows:

Application components are invaluable and cannot be overrated. Large .mxml files or ActionScript classes without clearly defined roles and responsibilities are a good sign that refactoring is necessary. When an application consists of many smaller components, it is often easier to work as a team, to debug an application, and to add new features or make changes to existing features. Too few components, or components that are too large and too complex, make applications difficult to manage. It is generally advisable to err on the side of too many components with responsibilities that are too granular than the other way around. As a rule of thumb, all components should have no more than two or possibly three key responsibilities. If a component has more responsibilities, it should be refactored into several more specialized components.

As we’ll see later in this chapter, we use application components extensively for the parts of the application that we call the views and the controllers. Almost universally, developers use application components for views. Our use of application components for controllers is somewhat less usual, but we think it provides a solution to issues that are unique to Flex. You can read more about views and controllers later in this chapter. You can read more about application components in general in Chapter 9.

Although versioning may seem like a related practices rather than a core practice, it is nevertheless a core practice that every team should be following for Flex projects. A variety of versioning software tools are available. Some of the most popular are Subversion (which we are using for the sample application), CVS, Mercurial, Git, Team Foundation Server, and Visual SourceSafe (VSS). Every versioning software works slightly differently, and different teams have different philosophies regarding how to manage code repositories. For example, some teams prefer not to add large assets (e.g., videos) to version control repositories, whereas other teams prefer the simplicity of adding everything to one location. What is most important is that you always add all source code to a repository, and you should always keep the repository up-to-date with changes. For the FlickrFlex project and many of our own projects, we like to add everything to the Subversion repository, including source code, Flex Builder project files, runtime assets, and compile time assets (embedded images, fonts, etc.).

Unit testing involves writing code that runs automated tests on project code. A test will run an assertion that will either pass or fail. A group of tests is known as a suite of tests. When running a suite of tests, you can quickly determine whether code is behaving as expected. If all the tests in a suite pass, it indicates that there is a good chance the application is working correctly. If one or more tests fail, it shows you where you should look to correct a problem with the code. Automated tests allow you to run suites of tests frequently, often every time you make a change to the code for an application. The results of the test will help you immediately identify any problems which new code might introduce.

Unit testing does not require that you use a testing framework. However, using an existing testing framework can greatly simplify writing and running test suites. There are two testing frameworks that we know of for use with Flex: FlexUnit (http://code.google.com/p/as3flexunitlib/) and AsUnit (http://www.asunit.org). We find that FlexUnit is a little easier to use with Flex than AsUnit.

Once you’ve starting writing unit tests, you’re likely to ask yourself exactly what you should be testing. Although it might be possible to write tests for every part of a Flex application, we find that it is generally easiest and most effective to write tests for only certain parts of an application. In particular, we find that tests for the following are most useful:

There is a philosophical approach to software development, known as test-driven development (TDD). This methodology advocates writing tests before writing application code. You then write the application code to get it to pass the tests. Some Flex developers find TDD works well for certain types of classes, such as model classes and business delegates. Other Flex developers don’t find that TDD is well suited to Flex development. We are mixed on the issue of TDD for Flex development, with one of us liking it and the other not. You’ll have to be the judge for yourself.

The sample application has a suite of tests that are included in the com.oreilly.pf3.flickr.test package, and the application also includes a test runner, TestRunner.mxml, to run the tests. You can see that there are two classes in the test package: PhotoTest and FlickrServiceTest. The PhotoTest case runs tests verifying that a Photo object correctly deserializes XML data as it is returned by the Flickr service. From a TDD perspective, it is useful to write this test before writing the Photo class and its deserialization method. Having the test written first can help to verify that Photo does what it is intended to do and that it meets all the requirements placed on it as you write it. However, even after the class has been written, the tests are useful because you can run them to verify that no regressions have occurred as you refactor the application. Likewise, it can be helpful to write the FlickrServiceTest class before writing FlickrService, and yet it is also useful after writing FlickrService to verify that the service works as intended.