I've done similar things in the past for non-multitasking tests; sorry
I have no code now to help you out. However, I suspect you'd want to
write these stub functions yourself anyway, especially since you are
unit testing. You likely to edit anyone else code anyway during the
testing process. Also if you use posix calls, as opposed to vxworks
calls, cross platform development and testing can be less troublesome.
Yes there is some overhead with including posix in your vxworks image,
but unless you in a "deeply" embedded device or extremely time
critical application I suspect you could handle the overhead. Maybe
posix won't be the answer to all your woes, but this is one of its
possible benefits.

I know you don't want to use Tornado or Workbench, and I truly commend
you for your stubbornest. If however you are someday forced to accept
reality as I was and at risk of sounding like a WRS employee, which
I'm not, I encourage you to look at the following product for unit
testing.

Specifically, if your vxworks image contains Sensorpoints, you can
cause malloc to return different values on each call, including null.
The point here is that you do not have to recompile you vxworks image
to change your test, because the sensorpoints module included in your
image handles all test case communications. Of course if you can do it
for malloc you can do similar things for any function call.

I just started playing with Wind River's Sensorpoints, which comes
with the "Workbench Diagnostics" package. I think it's around $3K per
seat. It would be very useful for unit testing. It certainly appears
to be a useful tool, especially if you add on the next level product
"Lab Diagnostics".

Anyway those are just my ramblings. good luck.