Preferred way to simulate system calls

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Preferred way to simulate system calls

Boost - Dev mailing list
I like to test every branch, and I have a class that calls
open/read/close.  It uses a hardcoded filename ("/dev/urandom").  It is a
template in a detail namespace.  What's the "boost way" when it comes to
mocking these system calls?  Should I make protected methods that normally
call open/read/close, then subclass in a test and  override them with
different logic to force error paths?

- Jim

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Preferred way to simulate system calls

Boost - Dev mailing list
On 11/07/17 01:00, James E. King, III via Boost wrote:
> I like to test every branch, and I have a class that calls
> open/read/close.  It uses a hardcoded filename ("/dev/urandom").  It is a
> template in a detail namespace.  What's the "boost way" when it comes to
> mocking these system calls?  Should I make protected methods that normally
> call open/read/close, then subclass in a test and  override them with
> different logic to force error paths?

I'm not aware of any mocking support in Boost. But I would be opposed
if, for the sake of testing, you would mangle the code so that
functionality or performance is affected. I.e. what you describe would
require these methods to be virtual, which is absolutely useless and
harmful in normal use.

I guess, if you really want to test you're actually calling
open/read/close, you could build a mocking library and use LD_PRELOAD to
inject it into the test. Or you could implement those functions in the
test itself, so that they are resolved to by the linker. Unfortunately,
I'm afraid you will have to deal with platform-specific linker API to
forward unrelated calls to the real open/read/close functions.

I don't think it is necessary to do a this deep test though. If you can
reasonably test that the generation works as expected (i.e. 10 calls
return 10 different conforming UUIDs), that would be enough. If you can
test the generator by replacing the random_device used in the test,
that's great. Just don't add any unnecessary overhead for that and don't
make it easy to use the test code in real code by accident.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Preferred way to simulate system calls

Boost - Dev mailing list
A better way than virtual is to make the code you want to test into a
template that takes a class parameter that provides the functions you want
to mock.  It's easy to make it testable while sacrificing no performance.

On Nov 6, 2017 14:57, "Andrey Semashev via Boost" <[hidden email]>
wrote:

> On 11/07/17 01:00, James E. King, III via Boost wrote:
>
>> I like to test every branch, and I have a class that calls
>> open/read/close.  It uses a hardcoded filename ("/dev/urandom").  It is a
>> template in a detail namespace.  What's the "boost way" when it comes to
>> mocking these system calls?  Should I make protected methods that normally
>> call open/read/close, then subclass in a test and  override them with
>> different logic to force error paths?
>>
>
> I'm not aware of any mocking support in Boost. But I would be opposed if,
> for the sake of testing, you would mangle the code so that functionality or
> performance is affected. I.e. what you describe would require these methods
> to be virtual, which is absolutely useless and harmful in normal use.
>
> I guess, if you really want to test you're actually calling
> open/read/close, you could build a mocking library and use LD_PRELOAD to
> inject it into the test. Or you could implement those functions in the test
> itself, so that they are resolved to by the linker. Unfortunately, I'm
> afraid you will have to deal with platform-specific linker API to forward
> unrelated calls to the real open/read/close functions.
>
> I don't think it is necessary to do a this deep test though. If you can
> reasonably test that the generation works as expected (i.e. 10 calls return
> 10 different conforming UUIDs), that would be enough. If you can test the
> generator by replacing the random_device used in the test, that's great.
> Just don't add any unnecessary overhead for that and don't make it easy to
> use the test code in real code by accident.
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman
> /listinfo.cgi/boost
>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost