HP (Mercury) tools do better with rich-clients

EddieC 0 252 Views

Hewlett-Packard today updates to and --its quality assurance tools for software testers--that the company says are now better equipped to help development teams find defects earlier and cover code for Adobe Flex/Flash, Ajax, Microsoft Silverlight and other rich client technologies.

New in Functional Testing 10, which is part of Mercury's ever-popular Quick-Test Pro, is the ability to easily test dynamic Web 2.0 applications and features. The update is implemented in the so-called Web 2.0 Extensibility Accelerator, which the company says "provides a Visual Studio-like IDE that accelerates and facilitates the design, development and deployment of HP QuickTest Professional Add-in Extensibility support sets." These support sets "extend the HP Functional Testing Web Add-in so you can test Web controls that are not supported out-of-the-box." Current QTP users can .

HP, which acquired the top-selling Mercury software testing tools along with Mercury Interactive in 2006, has the tools as part of its , which also includes tools for security, performance and SOA management.

Dani AI

Generated

Short answer for : it depends on how the C++ application renders its UI. HP’s functional/UI tools work at the UI layer, so they’re very useful when the app exposes standard, framework-backed controls or hosts supported runtimes. They’re much less helpful for pure native, custom-drawn, or GPU-rendered controls unless you add a layer that makes those controls visible to test automation.

Practical checklist to decide whether to use the HP tools (or a fallback approach):

  1. Identify the UI toolkit (MFC/Win32, Qt, wxWidgets, C++/CLI WinForms, embedded WebView, etc.).
  2. Start the test tool with any relevant add-ins and use the Object Spy/inspector to see how controls are exposed.
  3. If controls are recognized natively, build object-based tests and keep UI tests high-level.
  4. If controls are not recognized, consider these fixes: enable/implement accessibility (MSAA/UIA) so controls expose properties; add a thin automation wrapper (COM/.NET) that exposes standard control interfaces; or use image/“visual” testing as a last resort.
  5. Avoid relying on GUI tests for core logic—keep logic in unit-tested C++ modules and reserve GUI tests for flows and integration.

For native-heavy C++ projects it’s usually best to combine approaches: instrument the app (test hooks or accessibility), run fast unit tests for business logic, and use the UI tool only for a small set of end-to-end scenarios. The original thread touches on richer client tech; the missing piece here is that the testability of a C++ app is determined by the UI surface the app exposes, not by the language alone. ’s mention of richer clients is relevant — just map the C++ UI to what the tool can actually see before committing to a full test automation strategy.

Member Avatar for Salem
Salem 6,009 Posting Sage

Is any of that relevant to C++?

Member Avatar for EddieC
EddieC 0 Posting Whiz in Training

Sorry, I should have filed in Java section!

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.

Edit Preview