-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow for creation of mock DisplayObject from interfaces #55
Comments
Excellent idea. The superclass to extend will need to be specified before preparing the proxy classes though. When preparing: prepare({ "class": IUISubClass, "extend": Sprite }); Via Metadata: [Mock (extend="flash.display.Sprite")]
public var uiSubClass:IUISubClass; |
Moving the declaration into the preparation is much cleaner. And "extend" is also a better keyword. Sweet. :) |
Workaround for now: Create a skeleton class (empty method trunks) that extends Sprite (or MovieClip, or...) and implements the interface. Then use this class to create a mock object. |
To take this a step further it should allow specifying multiple interfaces: prepare({ 'class': Sprite, 'implement': [ IButton, ISelectable ] }) [Mock(implement="example.IButton, example.ISelectable")]
public var component:Sprite; |
Good point! Until then, the same workaround as above applies. |
When creating mock objects from an interface, all of its super classes are included in the mock objects type hierarchy. But interfaces in ActionScript can extend only other interfaces, and since DisplayObject, Sprite and MovieClip don't implement one, we can't type cast our mock objects to any of these. Hence, we lose the ability to use these mock objects as an argument in calls to
addChild ()
orremoveChild()
- which basically prevents the fully decoupled testing of UI elements.If a subclass of DisplayObject implements a custom interface, it should be possible to create a mock object, which extends from DisplayObject or one of its descendants, instead of just plain Object.
I would imagine a syntax like this:
or via metadata:
The same approach could of course also be useful for any other classes that need to be used in type casts to classes that don't implement an interface.
The text was updated successfully, but these errors were encountered: