How can I test linkable/executable files that require re-hosting or retargeting?

Question

Due to data protection, I cannot discuss fine details of the work itself so apologies

PROBLEM CASE

Sometimes my software projects require merging/integration with third party (customer or other suppliers) software. these software are often in linkable executables or object code (requires that my source code is retargeted and linked with it). When I get the executables or object code, I cannot validate its operation fully without integrating it with my system.

My initial idea is that executables are not meant to be unit tested, they are meant to be linkable with other system, but what is the guarantee that post-linkage and integration behaviour will be okay? There is also no sufficient documentation available (from the customer) to indicate how to go about integrating the executables or object files.

I know this is philosophical question, but apparently not enough research could be found at this moment to conclude to a solution. I was hoping that people could help me go to the right direction by suggesting approaches. To start, I have found out that Avionics OEM software is often rehosted and retargeted by third parties e.g. simulator makers. I wonder how they test them. Surely, the source code will not be supplied due to IPR rgulations.

UPDATE

I have received reasonable and very useful suggestions regarding this area. My current struggle has shifted into testing 3rd party OBJECT code that needs to be linked with my own source code (retargeted) on my host machine. How can I even test object code? Surely, I need to link them first to even think about doing anything. Is it the post-link behaviour that needs to be determined and scripted (using perl,Tcl, etc.) so that inputs and outputs could be verified? No clue!! :(

thanks,

Answer 1

Treat the executable like a black box. Make sure you have a software test harness that you can plug the executable into and verify it meets your expectations. That test harness doesn't need to represent your full code suite. It just needs to handle the cases you care about.

Looking at it from a broader level, you've been given a library that purports to meet a contract or an API. You need to be able to verify that the executable will meet the contract in the manner that you expect it to. Since you don't have the source code to visually inspect the implementation, you need to consider something else. To me, this screams for having a test suite of unit / integration tests to validate behavior.

Simply assuming that the black box executable will perform as promised is a foolhardy assumption. If the executable is mature, then it's a less risky proposition but there is still some risk. Your end users / clients won't care if your software fails or if the black box fails. To them, it is one and the same. From their point of view, your software is at fault.

Have a test harness. Create a step in your acceptance procedures to run new executables through the harness. Ideally, nothing will ever turn up as wrong. I've yet to see the ideal situation in software development though.