<u>FrameworkManager – for elegant, clean scripting with QTP.</u>
FrameworkManager lets you program better, cleaner tests by handling all the troubles and nitpicking of the application's UI level for you.
Besides providing an extremely simple interface to building and maintaining you scripts, FrameworkManager solves one of the biggest problems with QTP's native OR and DP. These mechanisms don't carry sufficient data from the real-world into the test (e.g. is an input field mandatory, are two fields connected etc.).
Usually we compensate by constructing huge Select-Case or If structures (if the field can only take Emails, do this, if it can take only addresses, do that), but they soon become too clumsy and complicated to maintain. Before you know it, introducing and new field to the application becomes a daunting task of repetitive code-fixes and patches. With FrameworkManager these are all things of the past.
FrameworkManager allows you to carry just the right amount of information from the real-world into your script, while keeping you code simple and tangle-free. Decision making structures are broken into separate mini-classes which can be maintained and updates with zero-risk of full-blown bugs and code-fixes. On top of it all, FrameworkManager is environment independent, and can be easily extended to handle unrecognized objects and controls.
Some of FrameworkManager features:
1. Keep you scripts clean and simple. Handling objects becomes as simple as oObject.Input .
2. Inherent handling of different input-types to the same real-world object type (e.g. two text fields, one take only Emails, the other only numbers).
3. Inherent handling of bundled actions – meaning, two or more object-manipulations which have a single logical consequence (e.g. pressing a button to confirm a field input, always input password and validate-password fields together).
4. Inherent handling of value validation options:
Delegation - you input the value in a certain object, but it appears in another.
Regular Expressions – you enter a certain value, but it appears with prefixes or suffixes.
5. Inherent handling of conditional input – you can easily set up flags to mark a certain object as "untouchable" (e.g. you have two fields which are enabled / disabled by a button. You must only press the button once, so once you press it, you mark it as untouchable for the second field).
6. Inherent handling of random values – select randomly from combo-boxes, list-boxes, etc.
7. Easily add meta-data (custom properties) to the application objects in order to carry business-logic data into you scripts (e.g. mark certain fields as mandatory; link between input field to the field that retrieves it in a query screen, etc.). You can then easily use the data in your scripts (e.g. immediately input all mandatory fields in a screen).
8. The application objects are structured as a tree, which allows you to incorporate complex object search operations to your scripts (e.g. input all the fields under a certain tab; climb up from a web-table to the hosting frame etc.).
9. Add fictitious levels to the object tree to better organize it. Finally have a human-readable object tree.
10. Extremely extendable – you can add new types of value generation and input methods without editing existing code. The main FrameworkManager code works "out-of-the-box" with any extension, unrecognized control and business logic process you have in your application.
As with all new frameworks, this might take a little while to get used to, but I've included a demo-app and an extensive readme to help the transition.
You can get FrameworkManager at the Project Homepage.
Hope you'll find it useful.