【开发】测试驱动的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，你永远不知道某个变更的需求到底是不是在不影响原有业务逻辑的情况下完成了。
强调测试驱动开发的好处之一就是避免这样的情况，开发者在编写程序的过程中就已经随手写好了所有代码的测试，那么任何改动，只需要将原来的测试执行一遍，便能够确认改动是不是在预期内达到要求了。 另外一个附加的好处就是能够让开发者能够有更多的时间来整理思路，考虑整个项目的架构设计问题， 通常情况下开发者总是拿到需求然后就开始编码，只管把当前的任务完成了就算，然而如果不对问题进行整体考虑，短期内似乎需求是满足了， 但是一旦发生需求变更，可能这次的修改还得重新再实现一次。 测试驱动的开发就是要把这种情况出现的概率尽可能的降低。 测试驱动的开发要求开发者将软件中相对独立的过程解耦出来便于测试， 因为与界面设计耦合的业务逻辑是无法测试的。
通常情况下，初级的开发者总是认为函数的产生是随意的，写到�
相关文档：
消息服务(Message Service )提供发布(publish)/订阅(subscribe)机制允许Flex 应用程序发布消息、订阅消息终端(messaging destination)，从而实现实时数据的推和协作。
一、Message Service
Message Service 提供发布(publish)/订阅(subscribe)机制允许Flex 应用程序发布消息、订阅消息终端(messaging des ......
flex滚动条虽然很好用，但总是会出现意想不到的问题。前几天说了，拖动后花屏的问题，今天又发现了更恶心的问题。当你把容器的宽度调为100%后 ，verticalScrollbarPolicy 用默认的auto。这是如果你缩放窗口会出现滚动条，但问题这是就出现了，只要出现了垂直滚动条，水平滚动条就是被迫出现。
<?xml version="1.0" enco ......
Flex中通过继承可以为新组件增加新的功能，如通过注入方法，改变背景色，改变位置和高度等。这里主要掌握原组件的一些特性，属性和方法，以便根据需要的功能加以覆写（也可以自己扩展），达到自己想要的效果。下面是一个简单的例子
1、新建MyDataGrid.as,继承DataGrid,覆写drawRowBackground方法，注入rowColorFunction方 ......
CategoryAxis有一个叫做labelFunction的属性，这个属性的定义：指定一个函数，用于定义为CategoryAxis的dataProvider中的各个项目生成的标签。
所以修改的原理：可以利用labelFunction得到每个Label，然后再对其进行修改。
片段代码：
<mx:horizontalAxis>
<mx:CategoryAxis id="ca"
&nbs ......
