In this article, we will see what is test harness and how it is applicable to testers. Let’s get started.
I am not a big fan of labels. If I have to check a few aspects before I determine whether or not QA can be started, I will make a list and perform the action.
In my opinion, it does not matter if I officially call it a “Test readiness review” operation or not. If I’m fulfilling my responsibilities, there’s no need for a label.
Test Harness: Definition and Relevance to Testers
I stand corrected. Recently, in my class, I was teaching the Agile-scrum model for software development. There was a question how is testing performed in an Agile method?
I was explaining two approaches – one is to include it in each sprint, and the other is a best practice I learned from personal experience, which is to have a separate QA sprint after the development one.
One of my students asked me if there was a name for the second one and I didn’t because I never emphasized the names. But at that moment, I felt how important it was to label a process appropriately and to make sure that we have a term to refer to the process we are talking about.
Therefore, today we are going to do just that: learn the process behind the term “Test Harness”.
As I have previously mentioned in some of my articles, understanding a lot from the literal meaning of the name is possible. Check the dictionary for the meaning of “Harness” and we will find out if it applies later.
There are two contexts to where Test harness is used:
- Automation testing
- Integration Testing
Let’s begin with the first one:
Context #1: Test Harness in Test Automation
In the automation testing world, Test harness refers to the framework and the software systems that contain the test scripts, and parameters necessary (data) to run these scripts, gather test results, compare them (if necessary) and monitor the results.
Let me simplify this with an example.
Example:
If I was talking about a project that uses HP Quick Test Professional (now UFT) for functional testing, HP ALM is linked to organize and manage all the scripts, runs, results, and the data is picked from an MS Access DB.
The following would be the test harness for this project:
- The QTP (UFT) software itself.
- The scripts and the physical location where they are stored.
- Test sets
- MS Access DB to supply parameters, data, or the different conditions that are to be supplied to the test scripts.
- HP ALM
- Test results and comparative monitoring attributes.
As you can see, software systems (automation, test management, etc.), data, conditions, and results become an integral part of the Test harness. The only exception being the AUT itself.
Context #2: Test Harness in Integration Testing
Now it is time to explore what test harness means in “Integration Testing”.
Integration testing involves putting together two modules (or units) of code that interact with each other and checking whether or not the combined behavior is as expected or not.
Ideally, integration testing of the two modules would be possible to carry out when both of them are 100% ready, unit-tested, and ready.
However, this is not a perfect world, which means one or more modules/units of code that are to be the constituent elements of the integration test might not be available. To solve this situation, we have stubs and drivers.
Stubs are usually pieces of code that are limited in their function and will substitute or proxy for the actual module of code that needs to take its place.
Example: To further explain this, let me use a scenario
If there is a unit A and Unit B that are to be integrated. Also, Unit A sends data to Unit B, or in other words, Unit A calls Unit B.
Unit A if 100% is available and Unit B is not, then the developer can write a piece of code that is limited in its capability (what this means is that Unit B if it has 10 features, only 2 or 3 that are important for integration with A) will be developed and is used for integration. This is called a STUB.
The integration would now be Unit A->Stub (substituting for B)
On the other hand, if Unit A is 0% available and Unit B is 100% available, the simulation or proxy has to be Unit A here. Therefore when a calling function is replaced by an auxiliary code, then it is called the DRIVER.
The integration, in this case, would be: DRIVER (substituting for A) -> Unit B
The entire framework: The process of planning, creating, and usage of stubs and/or drivers to carry out the integration testing is called the Test Harness.
Note: The above example is limited and the real-time scenario might not be as simple or as straightforward as this. Real-time applications have complex and composite integration points.
A few more things before we conclude:
Q. What are the benefits of a Test Harness?
Would you ask what the importance of breath for human life is?–it is intrinsic, isn’t it? Similarly, a framework to test effectively is like a given. The benefit, if we have to spell it out, I would say, is that every testing process has a test harness whether we consciously say that it is “the test harness” or not. It is like traveling knowing the route, destination, and other dynamics of the journey.
Q. What is the difference between a test harness and a test framework?
I think that comparing and contrasting is not often the right approach when understanding related concepts, because the lines are often blurry. To answer that question, I would say that the Test harness is specific and the Test framework is generic.
For example, a test harness will include the exact information of the test management tool down to the login IDs to be used. A test framework will simply say that a test management tool will do the respective activities.
Q. Are there any Test Harness tools?
Test harness includes tools like automation software, test management software, etc. However, there are no specific tools for implementing a test harness. All or any tools can be a part of Test Harness: QTP, JUnit, HP ALM- all of them can be constituent tools of any Test Harness.
Conclusion
As always, we at STH believe that we can derive even the most technical definitions from the term’s simple and literal meaning.
The dictionary on my smartphone tells me that a “Harness” is (look under the verb context): “To bring under conditions for effective use; gain control over for a particular end; “
Follow and adapt this to testing:
“A test harness simply is to create the correct framework and use it (and all of its constituent elements) to control the entire activity as to get the most out of the situation- whether automation or integration.“
About the author: This article is written by STH team member Swati S.
Like with any definition, opinions can vary when it comes to defining something. We value your opinions and eagerly await your thoughts. Feel free to leave any feedback, questions, or suggestions you may have in the comments section below.
Thanks for your feedback!
