Flex best practices – Part 2: Development practices
Application development frameworks
Using a framework you will greatly increase your chances of success, especially if your application contains a substantial amount of source code.
Consider using an application development framework
There is some disagreement about whether or not frameworks should be used when developing Flex applications. For enterprise level applications, as well as in teams of developers, frameworks are more generally recommended. My personal preference and recommendation is to use an application development framework. This enables a common language for the architecture of a codebase and provides direction for application development and scalability.
Use frameworks for team-based development efforts
Frameworks help teams to work together in a unified effort and can reduce the chances of duplicating development efforts.
Mate (pronounced "mah-tay") is a tag-based application development framework created for use with Flex. Mate is an unintrusive framework that allows for a loosely coupled codebase.
Cairngorm is the de facto standard for Flex application development. If you don't already know Cairngorm you should definitely consider learning it. For more information on Cairngorm, check out this great Introducing Cairngorm article. Adobe Consulting uses Cairngorm and fully stands behind it for their development efforts.
This is a pure ActionScript 3.0 Model-View-Controller application development framework. Futurescale, the makers of PureMVC, describe it as follows: "PureMVC is a lightweight framework for creating applications based upon the classic Model-View-Controller design meta-pattern… The PureMVC framework has a very narrow main goal: to help you separate your application's coding concerns into three discrete tiers; Model, View and Controller."
There are numerous other application development frameworks that can be used in conjunction with Flex or even just straight AS3 projects.
Know when NOT to use a framework
There are times when a framework is simply overkill for an application. If you are the sole developer of an application and you will be the only developer of the application for its lifetime, then you may not benefit from a framework. If you're developing something very simple, such as a banner ad, you can also skip the framework. The robust feature set offered by an application development framework is often not needed for very simple applications with limited data manipulation and minimal events. For another perspective, see this classic blog post by Steven Webster on the topic of when and when not to use an application development framework.Integrating unit testing
Unit testing can ensure the quality of your codebase. Writing test cases can lead to more reliable and better code. Testing your code will help find errors and save debugging time. Here are a few best practices that can be applied when implementing unit testing.
Test behavior instead of testing methods
Writing code to test private methods is not always needed. This should be evaluated on a case by case basis. Write code to test against an object's public API. Typically private methods are used internally by a class to support its public API.
Apply the "too simple to break" rule
Don't over test the codebase. If the method is a very simple one line method, like a getter method, don't worry about writing a test case for it.
Use standard OOP best practices in test cases
Follow the same OO methodology you use to write the rest of your application. Refactor test cases to move common functionality into base classes as appropriate.
Use clear and concise test method names
Follow the same method naming conventions used elsewhere in the application's codebase. Avoid generic names for test case methods. This helps other developers easily understand the relationship, responsibility, and purpose of the method.
Write simple test case methods
Keep test cases simple and limit the decisions that are made within them.
Use static values in the assertion method calls when possible
This reduces the chances for error in your test cases and improves the maintainability and understandability of the test code.
Document the test code
Add comments that explain what is being tested and why. Also, outline any special circumstances regarding the test.
Create independent unit tests
Each unit test should execute a single behavior for each method.
Limit assertions to one per test case
Multiple assertions in a single test case can lead to performance issues. In addition, if one assertion fails the other assertions will not be executed until the first assertion passes.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)