自动化测试（非UI），用于现有的Flash组件 [英] Automated testing (non-UI) for existing Flash component

问题描述

我建立并维护一组分配给出版商，并允许他们与我们的系统集成的Flash组件。目前，该组件没有用户界面，只是包含编译$ C $下我们的查询系统服务器，解析响应，并修改查询发送的PARAMS。这里有一个版本As2的和AS3版本的Flex和CS3。我们典型的工作流程是这样的：

I build and maintain a set of Flash components that is distributed to publishers and allows them to integrate with our system. Currently the component has no UI and simply contains compiled code for querying our system servers, parsing the response, and modifying the params sent in the query. There's an As2 version and AS3 versions for both Flex and CS3. Our typical workflow is like this:

1）加载组件 2）对组件设置参数 3）告知组件来查询我们的系统 4）等待事件表示响应已收到，并解析 5）在组件上调用方法来检索和利用分析数据

1.) load the component 2.) set parameters on the component 3.) tell the component to query our system 4.) wait for an event saying the response has been received and parsed 5.) call methods on the component for retrieving and using parsed data

我们已经谈了很多最近关于自动化这些组件的测试，并似乎有很多议论周围的框架，如AsUnit和的FlexUnit。但是，我从来没有能够掌握我怎么可能有效地使用这些之一。这些示例和教程总是吝啬对现实世界的例子，而是提供多种类型和过度code，测试是否一个实例函数返回NUM1 + NUM2。

We've been talking a lot lately about automating the testing of these components, and there seems to be a lot of buzz around frameworks like AsUnit and FlexUnit. However, I've never been able to grasp how I might effectively use of one of these. The examples and tutorials always skimp on real-world examples and instead provide multiple classes and excessive code for testing whether an example function returns num1+num2.

我唯一可以猜测的是，这些测试框架的目的是从一开始实施，规划，测试套件，测试运行，并在发展的开始内置的测试案例。

The only thing I can guess is that these testing frameworks are intended to be implemented from the start, with planning for the test suite, test runner, and test cases built in at the start of development.

我们组件的自动化测试将必须确保性能进行适当地设定，这些性能在请求中发送到我们​​的系统中，响应接收到的是正确的考虑的参数发送，所分析的数据，包括正确的信息，并且没有错误，不良反应，或无限解析环路引起的。

An automated test of our component would have to make sure properties were properly set, those properties were sent in the request to our system, the response received was correct considering the parameters sent, the parsed data includes correct information, and no errors, bad responses, or infinite parsing loops are caused.

我的问题是，有没有什么办法来自动现有的，分布广泛，成立Flash组件测试没有完全改写它放入一个测试框架？还是我误解了测试框架，这已经是可能的吗？

my question is, is there any way to automate testing of an existing, widely distributed, established Flash component without completely reworking it to fit into a testing framework? Or am I misunderstanding the test frameworks and this is already possible?

更新：感谢您的答复。我已经开始融入我的组件与AsUnit，并认为我有它如何能够帮助我一个pretty的很好的理解。然而，AS2 AsUnit不支持异步测试案例，和我有一个很难找到一个AS2单元测试框架一样。异步测试是对这个项目非常重要。有没有人有不同的框架，任何建议？谢谢！

UPDATE: Thanks for the responses. I have started to integrate my component with AsUnit and think I have a pretty good understanding of how it can help me. However, the AS2 AsUnit does not support asynchronous test cases, and I'm having a hard time finding an AS2 unit test framework that does. Asynchronous testing is REALLY important to this project. Does anyone have any recommendations for a different framework? Thanks!

推荐答案

我们正在用我们的项目的FlexUnit，我pretty的高兴。假设你的项目的设计与耦合一个相当宽松的程度，你不需要在所有要更换（如果有的话），以测试你的code。如果你已经在使用一个MVC框架，比如凯恩戈姆或的 PureMVC的，使用FlexUnit要结合pretty的无痛。

We're using FlexUnit on our project and I'm pretty happy with it. Assuming your project was designed with a fairly loose degree of coupling, you shouldn't need to change much at all (if anything) in order to test your code. If you're already using an MVC framework like Cairngorm or PureMVC, FlexUnit should integrate pretty painlessly.

我会说，不过，我的经验与Flash / Flex的单元测试是几乎没有积极的，因为它已经与其他语言如Ruby或.NET的原因有三。第一处在于动作code这样的高度是UI相关的，而这样的code是很难甚至无法进行测试。另一个原因是，测试运行不适合很好地被插入到一个持续集成环境，如的 CruiseControl.NET 或 CruiseControl.rb ，因为它需要一个人运行它，然后点击按钮。最后，单元测试的一个巨大的好处通常是可以一起覆盖分析工具运行如 NCover 或 rcov 。闪光/ Flex不适合以这种分析与出修改后的编译器，如 。

I will say however that my experience with Flash/Flex unit testing is not nearly as positive as it has been with other languages such as Ruby or .NET for three reasons. First being that such a high degree of actionscript code is UI related, and this sort of code is difficult if not impossible to test. Another reason is that the test runner doesn't lend itself well to being plugged into a continuous integration environment such as CruiseControl.NET or CruiseControl.rb since it requires a human to run it and click buttons. Lastly, a huge benefit of unit testing is usually that you can run it alongside a coverage analysis tool such as NCover or rcov. Flash/Flex doesn't lend itself to this sort of analysis with out a modified compiler such as Flexcover.

这篇关于自动化测试（非UI），用于现有的Flash组件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！