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

I’m not typically enthusiastic about labels. Let me explain my perspective.

In preparing for QA operations, I like to create a checklist of the things I need to ascertain. I don’t find it crucial to officially label this procedure as a “Test readiness review.” So long as I’m meeting my responsibilities, it seems unnecessary to give it a specific name.

In spite of this, I understand that I could be wrong. A recent incident reminded me of this. When discussing the Agile-Scrum model for software development in a class, a student asked: “How is testing executed in an Agile approach?” I explained two methods – one incorporated testing within each sprint, while the other, based on my own experience, suggested delaying QA testing to a separate sprint after the development sprint.

Another student asked if the latter method had a specific title, highlighting the value of correctly naming a process for clear communication.

With that said, this article aims to elucidate the details of “Test Harness.”

I have previously emphasized in my articles that a great deal can be inferred from the literal meaning of a term. I, therefore, urge you to refer to your dictionary for the meaning of “Harness,” after which we can explore its significance in this context.

The term “Test Harness” is used in two main settings:

1. Automation testing
2. Integration Testing

Let’s examine the first context:

The First Realm: Test Harness in Automation Testing

When it comes to automation testing, “Test Harness” pertains to the infrastructure and software systems that include the test scripts, required parameters (data), test result collection, comparison (if necessary), and result monitoring.

To make this easier to understand, consider the following example.

Example:

Imagine we are examining a project that uses HP Quick Test Professional (now UFT) for functional testing, HP ALM for handling and managing scripts, runs, and results, and an MS Access database as a data source. In this case, the test harness for the project includes:

• The QTP (UFT) software itself
• The scripts and their physical storage location
• The test setups
• The MS Access DB supplying parameters, data, and conditions for the test scripts
• The HP ALM
• The test results and tracking tools

As displayed above, software systems (automation, test management, etc.), data, conditions, and results are all essential components of the Test harness, excluding the application under test (AUT).

The Second Dimension: Test Harness in Integration Testing

Now, let’s delve into the concept of “Test Harness” in integration testing.

Integration testing merges two or more code modules or units that interact with each other, and checks if their combined behavior is as expected.

Ideally, integration testing should take place when all the participating modules or units are fully prepared, unit tested, and ready for integration.

However, in the less-than-perfect world we live in, some modules/units needed for integration testing might not be available. In such cases, we rely on stubs and drivers.

A stub is a piece of code that acts as a placeholder for the actual that is currently inaccessible.

Example: Allow me to elaborate with an example.

Suppose we have two units, A and B, that need integrating. For example, Unit A sends data to Unit B, or in other words, Unit A calls Unit B.

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

Conversely, when Unit A is unavailable and Unit B is ready, a placeholder or simulator of Unit A needs crafting. Here, the stand-in for Unit A is called a driver. The integration would be: DRIVER (acting as A) -> Unit B.

The overarching setup for planning, building, and using stubs and/or drivers in integration testing is what we label as the Test Harness.

Note: The example above is simplified. Real-world integration situations can be more tangled and might involve compound integration points.

Wrapping Up:

As a recurring theme at STH, we believe that even complex definitions can be boiled down to a term’s basic, literal interpretation.

My smartphone’s dictionary defines “Harness” (as a verb) as:

“To put to use for a practical purpose; gain control over something for a specific purpose.”

When this definition is applied to testing, we get:

“A test harness can be defined as constructing a suitable infrastructure and harnessing it (along with all its components) to effectively manage the entire process, whether in automation or integration testing.”

And that sums up our explanation.

Before we conclude, let’s touch upon a few more aspects:

Q. How is a Test Harness beneficial?

Questioning the value of a test harness in testing is like questioning the importance of breathing to human life – it’s intrinsic. Having a useful testing framework is fundamental. If asked to enumerate the advantages, I would say that every testing procedure implicitly includes a test harness, whether we deliberately tag it as “The Test Harness” or not. It’s like starting a journey with a clear understanding of the path, the destination, and all other involved factors.

Q. How does a test harness differ from a test framework?

Drawing comparisons and differences between concepts doesn’t always seem the best course to me, as boundaries can often be hazy. However, to answer the question at hand, I would suggest that a test harness is particular to a specific context, while a test framework is broader. For example, a test harness might include specific details about a test management tool, like login credentials, whereas a test framework would simply mention that a test management tool is utilized for relevant tasks.

Q. Are there dedicated tools to execute a Test Harness?

A test harness might involve using various tools, such as automation software and test management software. However, no specific tools are exclusively designed for implementing a test harness. Any tool or combination of tools can constitute a test harness, including QTP, JUnit, HP ALM, amongst others.

About the author: This article was penned by Swati S., a contributor at STH.

Just like with any definition, opinions can differ. We value your input and are eager to hear your take on this. Feel free to drop comments, questions, or suggestions below.