##Explanation Trying to get better unit test coverage of my server.

Because I did not want to do this ad-hoc I add some automated tools to my build scripts that do all the work.

In the test directory I have a Mock.def that defines the system calls I want to mock. It support two types of line #include and MOCK_SYSTEM_FUNC

When building the unit tests the MockHeaders.cpp is compiled and linked with the unit tests MockHeaders.h is forced on all the source files with the -include directive from gcc

The ThorMock.h can be included by and unit tests that want to mock out a system file.

##Building The Code That generates the three files is (Its part of the generalized Makefile I have so all my projects can now use the mocking technique). If anyobody can help make this neater I would appreciate the input.

So in unit test builds (or code coverage builds as I call them) there is an indirection. The system call is actually held in a variable and must be looked up. So there is a slight penalty when running the tests.

This indirection is not compiled into the debug or release versions. So these build do not see any indirection.

Sometime the system names are just too common. And defining a macro to override them will hit more of your function names then you actually want (examples are read() and write()). In these cases I have had to define a wrapper function in the header file:

##Explanation I'm trying to get better unit test coverage of my server.

Because I did not want to do this ad-hoc, I added some automated tools to my build scripts that do all the work.

In the test directory I have a Mock.def that defines the system calls I want to mock. It supports two types of line: #include and MOCK_SYSTEM_FUNC.

When building the unit tests, the MockHeaders.cpp is compiled and linked with the unit tests; MockHeaders.h is forced on all the source files with the -include directive from gcc.

The ThorMock.h can be included by unit tests that want to mock out a system file.

##Building The code that generates the three files is part of the generalized Makefile I have, so all my projects can now use the mocking technique. If anybody can help make this neater I would appreciate the input.

In unit test builds (or code coverage builds as I call them) there is an indirection. The system call is actually held in a variable and must be looked up. So there is a slight penalty when running the tests.

This indirection is not compiled into the debug or release versions. So these builds do not see any indirection.

Sometimes the system names are just too common. And defining a macro to override them will hit more of your function names than you actually want (examples are read() and write()). In these cases I have had to define a wrapper function in the header file:

Wit this my build scripts build three file:

Sometime the system names are just too common. And defining a macro to override them will hit more than you function names then you actually want (examples are read/write). In these case I have had to define a wrapper function in the header file:

Also because the functions are inline I am hoping that it will not cost me an extra function call in reality as these will be inlined. I then these wrapper functions in my code.

With this, my build scripts build three files:

Sometime the system names are just too common. And defining a macro to override them will hit more of your function names then you actually want (examples are read() and write()). In these cases I have had to define a wrapper function in the header file:

Also because the functions are inline I am hoping that it will not cost me an extra function call in reality as these will be inlined. I then use only the wrapper functions in my code.

Because I did not want to do this add-hoc I add some auto-mated tools to my build scripts that do all the work.

Because I did not want to do this ad-hoc I add some automated tools to my build scripts that do all the work.