What is Test Harness and How is it Applicable to us, Testers

I have reservations when it comes to labels. Let me explain why.

If there are certain factors I need to evaluate before commencing QA activities, I prefer making a checklist and carrying out the necessary actions. In my view, it’s not essential to officially designate this process as a “Test readiness review” – as long as I’m fulfilling my responsibilities, there is no need to assign a specific label to it.

However, I acknowledge that I may be mistaken. Recently, while teaching the Agile-Scrum model for software development during a class, a question arose: “How is testing performed in an Agile method?” I proceeded to explain two methods – one involved integrating testing within each sprint, while the other, based on my personal experience, recommended deferring QA testing to a separate sprint following the development sprint.

One of my students queried whether there was a specific name for the latter method, which made me realize the importance of appropriately labeling a process to ensure clear communication.

Therefore, in this article, I aim to teach you about the process behind the term “Test Harness.”

As I have mentioned in my previous articles, a lot can be deduced from the literal meaning of a term. Consequently, I encourage you to consult your dictionary to understand the definition of “Harness,” and we will determine its applicability in this case.

There are two contexts in which the term “Test Harness” is used:

1. Automation testing
2. Integration Testing

Let’s start with the first context:

The First Context: Test Harness in Automation Testing

In the realm of automation testing, “Test Harness” refers to the framework and software systems that encompass the test scripts, necessary parameters (data), test result gathering, comparison (if required), and result monitoring.

Let me simplify this with an example.

Example:

Suppose I am discussing a project that utilizes HP Quick Test Professional (now UFT) for functional testing, with HP ALM for organizing and managing scripts, runs, and results, and an MS Access database for supplying data. In this scenario, the test harness for this project encompasses:

• The QTP (UFT) software itself
• The scripts and their physical storage location
• The test sets
• MS Access DB providing parameters, data, and conditions for the test scripts
• HP ALM
• The test results and monitoring attributes

As you can see, software systems (automation, test management, etc.), data, conditions, and results all form integral parts of the Test harness, with the exception of the application under test (AUT).

The Second Context: Test Harness in Integration Testing

Now, let’s explore the meaning of “Test Harness” in the context of integration testing.

Integration testing involves combining two or more modules or units of code that interact with each other and verifying whether their combined behavior aligns with expectations.

Ideally, integration testing should occur when all involved modules or units are 100% ready, unit tested, and prepared for integration.

However, we do not live in an ideal world, which means that one or more modules/units required for integration testing may not be available. In such situations, we rely on stubs and drivers.

A stub is a code snippet that serves as a substitute or proxy for the actual module of code that is unavailable.

Example: Let me illustrate this further with a scenario.

Suppose we have two units, A and B, that need to be integrated. Let’s say Unit A sends data to Unit B, or in other words, Unit A calls Unit B.

If Unit A is fully available but Unit B is not, the developer can create a limited-capability piece of code (stub) to substitute for Unit B during integration. The integration would then be: Unit A -> Stub (substituting for B).

On the other hand, if Unit A is unavailable and Unit B is ready, a proxy or simulation of Unit A needs to be created. In this case, the substitute for Unit A is called a driver. The integration would be: DRIVER (substituting for A) -> Unit B.

The entire framework for planning, creating, and utilizing stubs and/or drivers in integration testing is referred to as the Test Harness.

Note: The above example is simplified, and real-world integration scenarios may be more complex and involve composite integration points.

In Conclusion:

As always, at STH, we believe that even the most technical definitions can be extracted from a term’s simple, literal meaning.

According to my smartphone’s dictionary, “Harness” (in its verb context) means:

“To bring under conditions for effective use; gain control over for a particular end.”

Applying this definition to testing, we can say:

“A test harness is simply creating an appropriate framework and utilizing it (along with all its constituent elements) to effectively control the entire activity, whether in automation or integration testing.”

That concludes our explanation.

But before we wrap up, let’s address a few more things:

Q. What are the benefits of a Test Harness?

Asking about the importance of a test harness in testing is like asking about the significance of breathing for human life – it is intrinsic. Having an effective framework for testing is a given. If we were to spell out the benefits, I would say that every testing process inherently incorporates a test harness, whether we consciously label it as “The Test Harness” or not. It is akin to embarking on a journey with knowledge of the route, destination, and all the other dynamics involved.

Q. What is the difference between a test harness and a test framework?

In my opinion, comparing and contrasting concepts is not always the best approach since the lines are often blurred. However, to answer this question, I would say that a test harness is specific to a particular context, while a test framework is more generic. For instance, a test harness may entail specific information about a test management tool, including login credentials, whereas a test framework would simply state that a test management tool is used for relevant activities.

Q. Are there any tools for implementing a Test Harness?

A test harness may involve the use of various tools, such as automation software and test management software. However, there are no specific tools solely dedicated to implementing a test harness. Any tool or combination of tools can be part of a test harness, including QTP, JUnit, HP ALM, and others.

About the author: This article was written by Swati S., a member of the STH team.

And, as with any definition, opinions may vary. We appreciate your thoughts and would love to hear your perspective. Please feel free to leave comments, questions, or suggestions below.