Co-author: Srinivasareddy Vanukuri
In the software development life cycle, testing is an important and major phase to identify defects in the software to certify it with quality. Automation testing is one of the methods to test the software and reduce human efforts. This automated testing approach helps to avoid errors that can happen during manual testing. Nowadays, the customers are eagerly looking for a software with a certificate of automation testing tool qualification.
In general, the automation testing tool setup will test the software quality, based on the software requirements or functionality. The tool consists of some set of binaries to test the software. In embedded systems, under the hardware and software environment, the testing setup can be configured, and the automation testing will run. So, the automation testing tool should adopt the testing setup irrelevant of the hardware, platform, and software, etc.
Even if the automation testing tool is run and developed in a high-level programming environment (like C#, .Net, etc.), then it should be able to run in a low-level programming environment too (C, C++). During embedded automation testing, in some cases, it will not accept the automation tool which is developed in high level programming environment. Let us consider one of the advanced programming languages, C#, which is a very advanced version of C and OOPS. C# has covered all the latest technology. It will fulfill all the requirement logic and development. But if we downgrade the same binaries which is developed in C#, surely it will be a challenge. C# can have object calling, creating, and returning, etc. But C doesn’t support object handling with fully OOPS. It couldn’t call C# exported DLLs directly in C. It is not feasible too, because of these challenges.
Here, this blog provides the two types of approaches for this challenge to achieve this.
Generic Block Diagram
For this scenario, there is one approach that can be achieved through communication protocol (like ethernet / serial) by transferring the testing binaries outputs to target binaries, which might be written in C. Based on the outputs/results, the automation testing can run by C scripting. Here, there is no change in the automation tool framework, additional effort is very minimum, but the testing coverage is less.
- No change in managed framework
- More effort
- Less sophisticated
There is another solution of writing a wrapper. Writing the wrapper might take very minimal effort. You need to create C++ project by adding the required binaries (DLLs) which is developed in C#. Then create a class which consists of the required list of API which need to be exported to C. Finally, this C++ dll or lib can be used in C environment. With this method, the programmer:
- Has to extend the framework with another layer by wrapper
- Additional effort is very minimum
- Less complex for the creation
So, the C# binaries can be run in C++, as well as, in C too. It will be applicable in all scenarios of development phases by calling the managed binaries in unmanaged environment.