Testing Flex RIAs for NJ Flex user group
•Descargar como KEY, PDF•
1 recomendación•771 vistas
Why to test? ● Automation testing and tools overview ● Flex Automation 101 ○ Flex Automation Framework building blocks ○ How to prepare you components for automation testing ● Using FlexMonkey for testing custom components
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (19)
Destacado
Destacado (20)
Similar a Testing Flex RIAs for NJ Flex user group
Similar a Testing Flex RIAs for NJ Flex user group (20)
Más de Viktor Gamov
Más de Viktor Gamov (7)
Último
Último (20)
Testing Flex RIAs for NJ Flex user group
- 1. Testing Flex RIAs Viktor Gamov, Farata Systems April, 27 2011
- 2. Agenda • Why to test? • Automation testing and tools overview • Flex Automation 101 • Flex Automation Framework building blocks • How to prepare you components for automation testing • Using FlexMonkey for testing custom components
- 3. Why to test?
- 4. Software Has Bugs • We want to minimize the number, and • We want change to safe • How?
- 6. Only person who can write code without bugs is ...
- 7. Only person who can write code without bugs is ...
- 8. Why Chuck Norris does not test?
- 9. Why Chuck Norris does not test? • His code is perfect
- 10. Why Chuck Norris does not test? • His code is perfect • He does not need code documentation and communication on the project
- 11. Why Chuck Norris does not test? • His code is perfect • He does not need code documentation and communication on the project • Perfect memory
- 12. Why Chuck Norris does not test? • His code is perfect • He does not need code documentation and communication on the project • Perfect memory • Refactoring without problems
- 14. Testing Flex RIAs • Unit testing
- 15. Testing Flex RIAs • Unit testing • Functional (UAT, QA)testing
- 16. Testing Flex RIAs • Unit testing • Functional (UAT, QA)testing • Integration testing
- 17. Testing Flex RIAs • Unit testing • Functional (UAT, QA)testing • Integration testing • Load testing
- 18. Automation testing tools overview • QTP • Selenium • Ranorex • FlexMonkey
- 19. QTP Pros: • All-in-one suite for automation testing enterprise applications • Supports large pool of software development environments like SAP , Web , Oracle etc. • QTP is easier to use and implement for both technical & non technical testers • Support libraries out-of-the-box with Flex(qtp.swc, qtp_air.swc)
- 20. QTP Cons: • Unstable work • Absence of IDE for debugging scripts • Only Windows and IE (sorry Mac and Linux • VBScript as scripting language • Not free and expensive
- 21. Selenium + Flex API • Web applications testing • Open source and large community • Cross platform (Selenium IDE - browser extension) • JavaScript as scripting language
- 22. Ranorex • Similar to QTP, but better • Support large amount supported technologies (.NET, WPF, Silverlight, Qt, Win32, Delphi, WFC, Java SWT, Web testing, Flash/Flex testing) and platforms • Script languages C#,VB.NET, IronPython • Integration with Visual Studio 2010 • Platform: Windows • Not free, ~$1590 for one license (full suite)
- 23. FlexMonkey • OpenSource (commercial support available) • Flex apps testing centric tool • Cross platform (console - AIR application ) • Generated FlexUnit 4 test code • Supports testing only Flex applications (no Flash) • Integration with Selenium IDE (FlexMonkium project)
- 24. The process of creating a custom component that supports automated testing is called instrumentation
- 27. Component delegate • instance of delegate class gets added for each instance of components • delegates know about the component which associated • adds listeners to interested events of component • decides what to do when an event occurs and calls appropriate method on Automation Manager • can provide additional methods which will be interested for testers
- 28. Automation Flow Core Flex API SystemManager Automation Delegates Automation API Automation Manager Delegates Delegates QTP FlexMonkey Selenium Agent Classes Agent Agent Agent Automation Tools QTP FlexMonkey Selenium
- 29. Flex Automation Framework building blocks • Component delegate (automation.swc, automation_dmv.swc ...., custom classes ) • Automation Manager (automation_manager.swc) • Tool Adapter (automation_monkey4.x.swc) • Testing Tool (FlexMonkey Console) • Environment configuration
- 30. [Mixin] metadata tag • use is to create static code blocks to initialize parts of your application • that static code will be executed when a preloader finishes loading of the application class and the SystemManager is ready to kick off [2 frame]
- 31. [Mixin] example import mx.managers.ISystemManager; //--------------------------------------------------- // Example //--------------------------------------------------- [Mixin] public class MyMixin { /** * called due to the fact that i've used the [Mixin] metatag * @param systemManager */ public static function init(systemManager:ISystemManager):void { // do something } }
- 32. How to prepare your components for automation testing
- 33. What is a custom component • A component extending from a standard component (No additional events, no additional properties) • A component extending from a standard component – Additional events/ additional properties • A component extending from a non container class, but the current class is a container.
- 34. What to do in delegate if component extending from standard component • Nothing! Use delegate classes shipped with Flex Framework
- 35. What to do in delegate if component extending from standard component + additional events or properties • Add Event listener to interesting event • Identify the details of the event which is needed to reply the event later • Pass event to record to automation manager • handle reply of the event
- 36. What do in delegate component extending from non container class, but the current class need to be threaded as a container • Expose required children • getAutomationChildren • getAutomationChildAt • get numAutomationChildren • Provide the child handler methods • createAutomaitonIDPart • resolveAutomationIDPart • createAutomationIDPartWithRequiredProperties
- 37. Using FlexMonkey for testing custom components Demo
- 38. Conclusion • Testing is a very powerful tool to help produce, maintain and impart confidence in your software • Actionscript 3 now has testing tools approaching the level available to Java developers • We should all be testing!
- 39. Resources • Enterprise Development with Flex, O’reilly, 2010 • GorillaLogic http://clck.ru/BXV4 • Ranorex Flex Testing http://clck.ru/BXUk • Automation Docs http://clck.ru/Bqbn • Blog on Flex Automation http://clck.ru/BqbU
Notas del editor
- \n
- \n
- \n
- \n
- \n
- \n
- Why Chuck does not write the tests?\n\nThis code is perfect\n\nIn the code, Chuck Norris never bugs. He is never wrong. If you find a bug in the code, Chuck - try to talk to him about it - just realize that it really necessary feature of the project.\n\nIt does not need code documentation and communication on the project\n\nIn fact, the documentation - this is just one way communication. Documenting code, we are dealing with a team (with the present and future), which works on the project. Tests - this is the best documentation. Paper documentation, developers do not read, and disappear somewhere, these papers and files all the time. In written comments to the code is not always possible to understand - what exactly meant by the author. In the same tests immediately clear how the code works, what he should do to get.\nChuck this is not necessary - he has one.\n\nPerfect Memory\n\nOn what projects you can work alone? Only those where you bought a plane ticket into a warm country where the customer you will not find. On all other projects you are working at least two people - you and you in the future. And you need to communicate with itself for implementation. Chuck manages fine without it - he remembers everything in their projects.\n\nRefactoring without problems\n\nChuck did not do the refactoring because his code right ideal. So what of situations where you need something to change or optimize and try not to break anything in the process, he just does not happen.\n\n
- Why Chuck does not write the tests?\n\nThis code is perfect\n\nIn the code, Chuck Norris never bugs. He is never wrong. If you find a bug in the code, Chuck - try to talk to him about it - just realize that it really necessary feature of the project.\n\nIt does not need code documentation and communication on the project\n\nIn fact, the documentation - this is just one way communication. Documenting code, we are dealing with a team (with the present and future), which works on the project. Tests - this is the best documentation. Paper documentation, developers do not read, and disappear somewhere, these papers and files all the time. In written comments to the code is not always possible to understand - what exactly meant by the author. In the same tests immediately clear how the code works, what he should do to get.\nChuck this is not necessary - he has one.\n\nPerfect Memory\n\nOn what projects you can work alone? Only those where you bought a plane ticket into a warm country where the customer you will not find. On all other projects you are working at least two people - you and you in the future. And you need to communicate with itself for implementation. Chuck manages fine without it - he remembers everything in their projects.\n\nRefactoring without problems\n\nChuck did not do the refactoring because his code right ideal. So what of situations where you need something to change or optimize and try not to break anything in the process, he just does not happen.\n\n
- Why Chuck does not write the tests?\n\nThis code is perfect\n\nIn the code, Chuck Norris never bugs. He is never wrong. If you find a bug in the code, Chuck - try to talk to him about it - just realize that it really necessary feature of the project.\n\nIt does not need code documentation and communication on the project\n\nIn fact, the documentation - this is just one way communication. Documenting code, we are dealing with a team (with the present and future), which works on the project. Tests - this is the best documentation. Paper documentation, developers do not read, and disappear somewhere, these papers and files all the time. In written comments to the code is not always possible to understand - what exactly meant by the author. In the same tests immediately clear how the code works, what he should do to get.\nChuck this is not necessary - he has one.\n\nPerfect Memory\n\nOn what projects you can work alone? Only those where you bought a plane ticket into a warm country where the customer you will not find. On all other projects you are working at least two people - you and you in the future. And you need to communicate with itself for implementation. Chuck manages fine without it - he remembers everything in their projects.\n\nRefactoring without problems\n\nChuck did not do the refactoring because his code right ideal. So what of situations where you need something to change or optimize and try not to break anything in the process, he just does not happen.\n\n
- Why Chuck does not write the tests?\n\nThis code is perfect\n\nIn the code, Chuck Norris never bugs. He is never wrong. If you find a bug in the code, Chuck - try to talk to him about it - just realize that it really necessary feature of the project.\n\nIt does not need code documentation and communication on the project\n\nIn fact, the documentation - this is just one way communication. Documenting code, we are dealing with a team (with the present and future), which works on the project. Tests - this is the best documentation. Paper documentation, developers do not read, and disappear somewhere, these papers and files all the time. In written comments to the code is not always possible to understand - what exactly meant by the author. In the same tests immediately clear how the code works, what he should do to get.\nChuck this is not necessary - he has one.\n\nPerfect Memory\n\nOn what projects you can work alone? Only those where you bought a plane ticket into a warm country where the customer you will not find. On all other projects you are working at least two people - you and you in the future. And you need to communicate with itself for implementation. Chuck manages fine without it - he remembers everything in their projects.\n\nRefactoring without problems\n\nChuck did not do the refactoring because his code right ideal. So what of situations where you need something to change or optimize and try not to break anything in the process, he just does not happen.\n\n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- The SystemManager class creates the display list, a tree of visible objects that make up your application.\nEach time a new component is added, either at the root of the display list or as a child of another member of the display list, SystemManager dispatches an Event.ADDED event.\nThe AutomationManager listens for the ADDED event. In its ADDED event handler, it calls methods on the Automation class. It then instantiates the delegate for that class.\nThe Automation class maps each component in the display list to its full class name.\nWhen it is created, the delegate class adds a reference to its instance in the delegate class map. The delegate class then handles events during record and play-back sequences.The delegate is now considered registered with the component. It adds event listeners for the component’s events and calls the AutomationManager when the component triggers those events.\nAfter the components in the display list are instantiated and mapped to instances of their delegate classes, the AutomationManager is ready to listen for events and forward them to the agent for processing.\n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- E.g. user creates an MyAdvancedDataGrid extending from AdvancedDataGrid.\n i.e no special user interaction possibilities on it other than the base component.\nE.g. user creates MyComponent extending from Panel and have some controls in it. \ni.e the new component is a container, and the base also a container. \nWhat to do here? \nNothing. The base component automation (delegate) will take care of the needed. \n\n
- E.g. user creates an MyAdvancedDataGrid extending from AdvancedDataGrid.\n and there is a new event which needs to be recorded.\nUser extends from a component, but wishes to expose a behavior which is different \nfrom that of the standard component.\nWhat to do ?\nCreate a new Delegate\nAdd in the new delegate to the application using -includes\nProvide the details of the component in the XML file\n\n\n
- \n
- \n
- \n
- \n
- \n