【开发】测试驱动的FLEX开发 使用FLEXUNIT
http://elromdesign.com/blog/2010/03/10/test-driven-development-tdd-with-flexunit-4-complete-tutorial/
本来是打算完整的翻译完成这篇博文的，一边翻译，一边谈谈自己对驱动测试开发的理解。 当然我的理解和原文作者的理解不一定一样，但是至少，我们都承认开发得是测试驱动的。 然而CSDN的博客系统是实在不能理解【无法大篇幅的CP过来】， 那我就引用一下这篇文章。 稍微谈一下我对测试驱动的开发的理解。
这篇文章无疑是很值得一看的，而且带有详细的例子演示了测试驱动的开发。 在FLEX这样一个界面侧重的框架中，测试驱动更是必不可少的。其实要看懂这篇文章并不困难，熟悉FLEX的人可能都不屑于看这种TUTORIAL，我觉得引这篇文章的主要目的是强调测试驱动开发的重要性，特别是在FLEX这样的框架下面。
传统的软件过程中，测试是独立于开发部分的，（我还是乐于讨论软件工程的东西），开发者完成开发后交给测试者进行测试，发现问题，开发者修改，然后再测试。 似乎是没有问题的，问题就在于代价，这样的一次改动带来的时间消耗是可观的，特别是在需求变动频繁的情况下。之所以强调测试驱动的开发在FLEX下的情况，就是这个道理，FLEX是偏向于客户端，偏向于界面的东西。 而外观是整个软件系统中最容易发生变化的部分，每个人对界面的定义都是不同的，因此在项目的迭代过程中会带来大量的界面更改的需要，这些界面如果耦合着业务逻辑，而且没有测试代码的话，这种修改代价可以想象，你永远无法知道系统中到底是不是还有隐藏的bug，你永远不知道某个变更的需求到底是不是在不影响原有业务逻辑的情况下完成了。
强调测试驱动开发的好处之一就是避免这样的情况，开发者在编写程序的过程中就已经随手写好了所有代码的测试，那么任何改动，只需要将原来的测试执行一遍，便能够确认改动是不是在预期内达到要求了。 另外一个附加的好处就是能够让开发者能够有更多的时间来整理思路，考虑整个项目的架构设计问题， 通常情况下开发者总是拿到需求然后就开始编码，只管把当前的任务完成了就算，然而如果不对问题进行整体考虑，短期内似乎需求是满足了， 但是一旦发生需求变更，可能这次的修改还得重新再实现一次。 测试驱动的开发就是要把这种情况出现的概率尽可能的降低。 测试驱动的开发要求开发者将软件中相对独立的过程解耦出来便于测试， 因为与界面设计耦合的业务逻辑是无法测试的。
通常情况下，初级的开发者总是认为函数的产生是随意的，写到�
相关文档：
从网上转载的，还没时间鉴定，暂记录在这里
http://blog.csdn.net/zyjasp/archive/2008/05/16/2452175.aspx
第一步:建立加载类[CtmObjLoader],此类可以加载文件类型 [图片文件或swf文件]
package
{
import flash.display.DisplayObject;
import flash.display.Loader;
import flash.events.*;
import flash. ......
工作流应用在企业信息化建设中越来越来普及，而且用户常常要求自己可以在一定程度根据自己业务需求对流程进行修改。而我们以前做流程设计器都是基于C/S模式，这样就造成用户在使用的时候需要来回切换两个系统，而且这种架构不利于程序统一升级。所以我打算开发一个基于Flex的流程设计器。 从以往经验来看，做� ......
这两天准备学习Flex,于是下载了Flex Builder 3.0 For Eclipse plugin准备安装.
但是安装后启动Eclipse,找了半天也没找到Flex.而且Flex Builder会把JRE也安装.觉得这样很不爽.
所以我想到能不能来个Flex Builder绿色安装方法呢.
想到就做.下面是我的安装过程.(前提是系统已经有JRE,且JAVA环境变量已经配置OK,此处略过� ......
CategoryAxis有一个叫做labelFunction的属性，这个属性的定义：指定一个函数，用于定义为CategoryAxis的dataProvider中的各个项目生成的标签。
所以修改的原理：可以利用labelFunction得到每个Label，然后再对其进行修改。
片段代码：
<mx:horizontalAxis>
<mx:CategoryAxis id="ca"
&nbs ......
