Testing Flex RIAs for NJ Flex user group

Editor's Notes

• #2: \n
• #3: \n
• #4: \n
• #5: \n
• #6: \n
• #7: \n
• #8: 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
• #9: 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
• #10: 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
• #11: 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
• #12: \n
• #13: \n
• #14: \n
• #15: \n
• #16: \n
• #17: \n
• #18: \n
• #19: \n
• #20: \n
• #21: \n
• #22: \n
• #23: \n
• #24: 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
• #25: \n
• #26: \n
• #27: \n
• #28: \n
• #29: \n
• #30: \n
• #31: \n
• #32: 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
• #33: 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
• #34: \n
• #35: \n
• #36: \n
• #37: \n
• #38: \n