7

I am currently unit testing some C code and I am faced with a problem:

Within the code there are called functions that contain inline assembler code for the SPARC 8 architecture.

Since I am doing the unit tests on a x86 architecture, it obviously can't be compiled. Unfortunately, testing it on the target plattform is not possible for me.

What do you think would be a proper approach for this problem? Should I modify the original code by enveloping the inline assembler code with #ifdef UNIT_TEST #endif, or is there an alternative solution?

  • I guess running your unit tests on the target architecture (SPARC 8) is out of the question. If that's the case, you could state it in the question to narrow down the problem. – COME FROM Jan 18 '16 at 10:34
  • Yes, thats the case. Thanks for the tip, I added this information to my question. – christianh Jan 18 '16 at 11:16
  • "testing it on the target plattform is not possible for me" - well, someone is going to run the code on the target machine and thus "testing" it - who is this, and why can't you do it? – Doc Brown Jan 18 '16 at 12:02
  • QEMU can emulate a SPARC V8. Perhaps you could run your SPARC unit tests on an emulator. – TMN Jan 18 '16 at 13:25
5

No one said unit tests have to be run all on the same platform - but no one said you could reach 100% test coverage either.

As a first step, #ifdef out the code, preferably factoring it into a platform-specific function. Write a suitable implementation of this function for x86. However, I don't think it is appropriate to select the code to be compiled based on "unit testing" or "not unit testing". Rather, simply use the architecture: x86 or SPARC.

Now continue working on your tests and on your program. Simply document the "hole" in testing you have created: the function, while unit-tested on x86 is not unit tested on SPARC. Just don't stop your progress because you have not figured out yet how to test this particular piece of code.

Assuming you had written this piece of assembler for a good reason (such as e.g. a very frequently used routine called in tight loops) you should now feel uncomfortable. The good news is that unless you ship yesterday, you have some time to patch the hole. Here are some ideas:

1) You are probably doing integration testing (or field tests, or anything higher-level than unit tests). If the observed behavior is as per spec, then your assembler code is probably fine. At the end of the day, it's all about the testing conditions: if your integration testing includes most of the operational conditions, then you are OK. Granted, you won't get the same feedback than with unit tests (the loop will be longer; the failure will not be as precise as "expected this, got that" and harder to investigate) but still: your code is tested.

2) You might have some colleagues around, who will be happy to do a code review on this specific part.

3) You could try to use an emulator (QEmu seems to support SPARC archs). I have no idea if this could pay back, but why not give it a shot?

4) Are you 100% sure you can't have your hands on the target machine? How much is going to cost a defect in this code? If it's more than a few days of work, then you can probably convince your manager to buy an old Sun station to run tests on. Testing always look too expensive at first sight, but it's like an insurance, or an investment. Really, hardware is cheap compared to man-hours, lost company benefits (or, even worse, court trials).

To sum up: either you feel you must unit test your code (and in this case, make it happen by ruling out the "impossible for me" part), or rely on other forms of testing.

  • Fewer true statements have ever been written than point #4 above. Throwing a budget case (especially when there are bean counters present) can quickly tip the decision. – zarchasmpgmr Jan 19 '16 at 16:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.