【开发】测试驱动的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，你永远不知道某个变更的需求到底是不是在不影响原有业务逻辑的情况下完成了。
强调测试驱动开发的好处之一就是避免这样的情况，开发者在编写程序的过程中就已经随手写好了所有代码的测试，那么任何改动，只需要将原来的测试执行一遍，便能够确认改动是不是在预期内达到要求了。 另外一个附加的好处就是能够让开发者能够有更多的时间来整理思路，考虑整个项目的架构设计问题， 通常情况下开发者总是拿到需求然后就开始编码，只管把当前的任务完成了就算，然而如果不对问题进行整体考虑，短期内似乎需求是满足了， 但是一旦发生需求变更，可能这次的修改还得重新再实现一次。 测试驱动的开发就是要把这种情况出现的概率尽可能的降低。 测试驱动的开发要求开发者将软件中相对独立的过程解耦出来便于测试， 因为与界面设计耦合的业务逻辑是无法测试的。
通常情况下，初级的开发者总是认为函数的产生是随意的，写到�
相关文档：
·下面介绍Flex与.NET的WebService的数据通信知识点;包括连接WebService，远程调用WebService方法，给WebService方法传递参数等相关知识点。
<mx:WebServiceid="dataService"
wsdl="http://localhost/FlashFlex/DataWebService.asmx?wsdl"
useProxy="false">
<mx:ope ......
由于本人最近忙于找工作和毕业设计，没有时间来继续这个系列， 只写了第一篇，自己也深感惭愧，这一篇介绍一下这个demo的整体架构吧，先贴下下载地址。http://download.csdn.net/source/2118707
目前服务端已完成登陆注册模块，使用Socket编程，TCP协议。等服务端完成将完整的编写一个系列的教程。~~
......
今天刚接触Flex，但是当我把代码编写完成运行的时候报下了如下错误：
C:\WINDOWS\system32\Macromed\Flash\Flash10e.ocx
Flex Builder cannot locate the required debugger version of Flash Player.
You might need to install the debugger version of Flash Player 9 or
reinstall Flex Builder.
Do you want to ......
老生常谈的话题了。
首先是转帖部分：
http://kingwind.blogbus.com/logs/44323315.html
先来看Flex调用JavaScript中的函数
FlexConnectJavaScript.mxml
<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute">
<mx:Script> ......
