The term 'Harness' in general refers to a 'Tool' for controlling something. The same rule goes for software testing as well. In Software Testing, Test Harness is a collection of software, test data, test drivers, and tools specially developed to test an application under various environments. Developers then analyze the results of the tests to ensure a satisfactory outcome.
Test Harness can be called a process that does all the testing works, such as executing tests via test libraries and generating reports. For that, developers and testers have to develop specific test scripts to handle particular test scenarios and test data.
Test harness starts with data prep, a process of accumulating prerequisite data. Once the test harness is executed, testers must ensure they can perform all tests and generate reports by clicking one button or a single command.
As stated above, a test harness comprises a collection of different things to test an application and reports its outcome. A test harness could be anything. It could be a collection of unit test/tests that you wrote while developing an application. You can also go for other tests for your app's functionalities, such as checking user logs in your site, recent messages, notifications, etc.
The following process involves adding a test running compatible with your test scripts and run them all at a time. In short, a test harness includes a collection of concepts rather than a single software.
A Test case defines the objectives, descriptions, prerequisites, and expected results of a test. Meanwhile, A Test Script is an automated script executed to do a test.
In automation testing, Test Harness is known as a framework and system containing test scripts. Along with that, it also includes the necessary parameters necessary to run those scripts. After accumulating test results, testers compare them with other data and monitor the results.
Let's conduct 'functional testing' using the Unified Functional Testing tool. We are using the Application Life Cycle Management (ALM) tool for organizing, managing, executing, and monitoring the scripts. Similarly, we use MS Access DB as a database.
Now The Test Harness for the project will be −
The UFT software
Scripts and their storage location
MS Access DB for supplying parameters, and other relevant data
The test results
Attributes related to comparing and monitoring test results
Apart from the AUT, all the software systems, data, conditions, results serve as a significant part of the Test Harness.
Integration Testing is a part of software testing where individual units and components are combined and tested to see whether they behave as expected or not. The reason behind integration testing is to find errors when units are integrated and interacts with each other.
You can only carry integration testing if both the modules are 100 percent ready and Unit tested. However, this rarely happens because some modules supposed to be used for integration tests may not be available at the time. In such conditions, you can use test stubs and test drivers.
A Stub consists of a piece of code carrying limited functions. You can use them as a substitute for an actual code module.
Let's assume we decided to integrated Unit I and Unit II, where Unit I sends data to Unit II. We can also call this as Unit I calls Unit II.
In our scenario, Unit I is 100 percent available, but not Unit II. We can write a piece/s of code with limited capabilities and use it for integration in such a case. Meaning, if Unit II has 15 features, and we only need 3 or 4 elements to integrate it with Unit I, we will write a code consisting only of those features rather than writing the whole. This particular piece of code consisting of those limited features is known as Stubs.
We can write the integration as Unit I → Stub (substitution of B)
Alternatively, if Unit I is absent and Unit II is available 100 percent, we will consider Unit I for the simulation or proxy. The driver refers to the process when we replace a calling function with an auxiliary code.
In other words, Test Drivers are used as temporary replacements for a calling module as they offer the same output as an actual product. They are often required for software while interacting with an external system. Test Drivers are often complex than stubs.
We can write the integration as DRIVER (substituting for A) → Unit B
Processes involved in planning, developing, and using stubs or drivers to execute an integration testing are known as the Test Harness.
A test harness allows developers and testers to run automation more efficiently that eventually enhances productivity. Besides, it also helps in improving the quality of the software through debugging. It allows testers to schedule upcoming tests, especially in complex conditions. Apart from that, it also helps in automated report generation and recording test results.
A test harness comprises a set of dummy programs (stubs and drivers) written in JAVA, .NET, etc., to promote interaction with software under test. It is made of information required to compile and execute test cases, stubs, TDP, source code files.
A Test Automation Framework contains procedures, intellectual concepts, and environments allowing testers to design and implement tests. It comprises test libraries, automated testing tools, testing platforms, and complying with best testing practices.
The concept of the difference between Test Harness and Test Framework falls under blurry lines. You can consider test harness as specific while test framework as generic.
Some of the tools for test harness fall under the category of automation software and test management software. One cannot execute a test harness with a single tool. However, a combination of tools like QTP, HP ALM, Junit, etc., are often used by testers.