Flex、Flexunit:如何测试一个事件被调度两次?
我正在 Flex 应用程序中测试一些事件调度代码,使用 FlexUnit 的 addAsync
方法来测试事件的调度。 到目前为止,一切都很好,我可以确保至少有一个事件被触发。 不过,我想更详细一点; 我想确保准确地调度我期望的事件集。 是否有一个有用的测试模式(或者甚至不同的测试框架——我很灵活!)来完成这个任务?
我尝试了这段代码,但第二次似乎没有被调用:
protected function expectResultPropertyChange(event: Event, numberOfEvents: int = 1): void {
trace("Got event " + event + " on " + event.target + " with " + numberOfEvents + " traces left...");
assertTrue(event.type == ResponseChangedEvent.RESPONSE_CHANGED);
if (numberOfEvents > 1) {
event.target.addEventListener(ResponseChangedEvent.RESPONSE_CHANGED, addAsync(expectResultPropertyChange, 1000, numberOfEvents - 1));
}
}
public function testSomething(): void {
requiredQuestion.addEventListener(ResponseChangedEvent.RESPONSE_CHANGED, addAsync(expectResultPropertyChange, 1000, 2));
requiredQuestion.responseSelected("1", true);
requiredQuestion.responseSelected("2", true);
}
I'm testing some event dispatch code in a Flex app, using FlexUnit's addAsync
method for testing that events are dispatched. Great so far, I can ensure that at least one event was fired. However, I want to be a bit more detailed; I want to ensure that exactly the set of events I'm expecting are dispatched. Is there a useful test pattern (or, even, different test framework -- I'm flexible!) to accomplish this?
I tried this code, but it doesn't seem to get invoked the second time:
protected function expectResultPropertyChange(event: Event, numberOfEvents: int = 1): void {
trace("Got event " + event + " on " + event.target + " with " + numberOfEvents + " traces left...");
assertTrue(event.type == ResponseChangedEvent.RESPONSE_CHANGED);
if (numberOfEvents > 1) {
event.target.addEventListener(ResponseChangedEvent.RESPONSE_CHANGED, addAsync(expectResultPropertyChange, 1000, numberOfEvents - 1));
}
}
public function testSomething(): void {
requiredQuestion.addEventListener(ResponseChangedEvent.RESPONSE_CHANGED, addAsync(expectResultPropertyChange, 1000, 2));
requiredQuestion.responseSelected("1", true);
requiredQuestion.responseSelected("2", true);
}
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
回应评论...
..在这种情况下,您不需要使用模拟或 addAsync。 像这样的事情会做:
In response to the comment...
..in that case you don't need to use a mock or addAsync. Something like this will do:
这将是一个高级示例,说明如何使用进行异步调用的模拟对象来解决类似的问题。 显然我看不到你的代码,所以我无法给你一个准确的例子。
因此,正如我在评论中所说,您可以模拟类中的依赖项来伪造异步调用,以便它们变得同步。 采用下面的类
,因此默认情况下您将使用您想要使用的具体类,除非通过构造函数将 someAsynchronousObjec 注入到该类中。 AsycnhronousObject 可能有它自己的单元测试,或者它位于外部类中,因此您并不真正想要或需要测试其功能。 您现在可以做的是创建一个实现 IAsynchronousObject 的模拟对象,该对象可用于伪造其行为。 使用 ASMock 框架,测试可能如下所示:
这只是模拟如何帮助您进行单元测试的示例之一。 尽管对于 ActionScript(12 月发布)来说它仍然很新,但关于模拟的信息非常丰富。 ASMock 基于 .net Rhino 模拟,因此如果您需要帮助,搜索 Rhino 模拟应该会得到更多结果。
绝对是一种不同的思维方式,但是一旦你进入它,你就会想知道如果没有它们,你是如何进行单元测试的。
This is going to be a high level example of how a similar problem could be solved using a mocked out object of whatever it is that's doing the asynchronous call. Obviously i can't see your code so i can't give you a precise example.
So, as i said in the comment, you can mock out a dependency in a class to fake asynchronous calls so that they become synchronous. Take the below class
So by default you are using the concrete class that you want to use unless someAsynchronousObjec is injected into the class via the constructor. AsycnhronousObject probably has it's own unit tests or it's in an external class so you don't really want, or need to be testing its functionality. What you can now do is create a mock object that implements IAsynchronousObject that can be used to fake its behavior. Using the ASMock framework the test could look something like this:
This is just one example of how mocking can help you unit tests. There's a whole wealth of info out there on mocking although it is still very new to ActionScript (released in December). ASMock is based on the .net Rhino mocks so searching for Rhino mocks should throw up a lot more results if you need help.
Definitely a different way of thinking but once you get into it you tend to wonder how you got by in unit testing without them.