Windows app control

Introduction

Controlling windows app can be useful for automation of processes or for testing. This article provides more insides on possible ways to control application in windows by build-in methods, that are:

  • SendKeys mechanism – that simulates sending keystrokes to the current application
  • Windows GUI
  • IE OLE

Send Key

This way allows to send keystrokes to virtually any active windows application.  The downside is, that the active application can change anytime, so the keystrokes will go to another application.

Windows GUI

It is specific to a given application. It requires knowledge of the application, the GUI components. The components can be addressed by:

  • Windows handler that is globally unique but is dynamically assigned by the operating system.
  • programs ID that is assigned at programing/compilation time and should be unique and remains constant for an application.

Addressing by program ID is more recommended.  Please use tools like Spy++ (or write your own one based on the example) in order to check application’s GUI components.

IE OLE

The method can be used to control HTML documents loaded by IE. It assumes knowledge of the GUI object  “Internet Explorer_Server” and OLE (see Object Linking and Embedding) object ID “626FC520-A41E-11CF-A731-00A0C9082637” that represents the internal HTML document.

Using OLE for controlling HTML pages is more complex due to the nature of HTML.

The example

It requires .Net and has been tested with Win 7 and 8.1

Included examples:

  1. RunKeys with notepad
  2. RunKeys with calculator
  3. GUI with calculator
  4. IE OLE (it assumes only one IE instance with one tab is opened)

The program waits after each example until the current windows will be closed.

Check this VB source code example: WinControlExample

Add mshtml to the project for compilation.

MS_mshtml

 

Advertisements

Database test models

It will be nice to have automated continues tests for a database. Unfortunately testing a database is not as simple as testing an applications. Let’s consider there different models for testing a database.

Directly calling database procedures/functions and verifying responses.

This model is suitable for unit tests as it allows direct access to database objects. On the other hand testing complex use cases might require a series of calls that makes it more difficult.

Calling business application that is connected to database and verifying responses.

This model is suitable for testing business functionality through the business applications. But it is not suitable for unit tests or testing asynchronies processes as the responses might not always be available from the application or might not include all expected details about how the database performed a request.

Calling business application that is connected to database and verifying database changes/events.

It is the most complex model. It uses business application to request calls to the database and it assumes that the database has an agent that detects specific database events. The events are stored in event log and based on that a database monitor can process the events and forward it to the test engine for matching. The model is suitable for both low-level unit tests of elementary database objects as well as for testing complex business functions including asynchronies processes. On the other hand the model requires additional resources to run the agent, log and database monitor. And it requires more configuration to define and detect database events and additional configuration to match calls with events that might arrive asynchronously. One technique that helps to simplified the matching process might be adding distinguish identifier to each test if the application allows it and then storing the identifier with each change within the database. A practical example of an identifier could an USER id. To run a test in this model it will required a configuration of series of tests, and each test must include four configuration elements:

  • Definition of a call to application.
  • List of events that the Database Event Agent should watch for and then store to Event Log (both positive and negative).
  • List of events that Database Monitor should forward to the Test Engine.
  • Matching rules for the Test Engine that will define success and fail results.

The model might be suitable for continues integration of a complex database systems.