small medium large xlarge

13 Jun 2014, 15:44
Joao Ferreira (2 posts)


I have a (maybe) dumb question. On MockIO.c there is a IO_Write function that (I think) replaces the original one implemented on IO.c.

I don’t really understand where in the make process this happens.

Can someone enlight me?

Also it would be good to have a detailed presentation about how the makefiles are set up. At the moment I feel that the ‘code’ folder is a bit of a mess.

22 Jun 2014, 01:38
Richard Hagberg (10 posts)


If you look in 8.3 Link-Time Substitution in the book, James talks about Link-Time Substitution. In appendix A1.2, James talks about the need to use makefiles to perform link-Time substitution. I am pretty sure this is what he is doing in the MockIO tests to get the mock IO_Write function to override the IO_Write which is already created in IO.c. Between these two parts of the book, I get the feeling that you need a makefile to do this.

23 Jun 2014, 15:37
Joao Ferreira (2 posts)

Hey thanks for your reply.

I have the same feeling. I only wish that the makefile creation was explained a bit better.

I understand that it is not the main scope of the book, however I feel that is one of the hardest part. The trouble of setting up an environment to develop using the test-driven approach is driving me a bit crazy.

Maybe the appendices could be a bit more in-depth. Do you have any suggestion where I can dig more information?

23 Jun 2014, 19:08
Richard Hagberg (10 posts)

In doing a little more playing around, I have found out that at least in Visual Studio, as long as you set up the production code project as a library and the tests as a console application project, it will use the spies and mocks created in the test project before the original functions in the production code library. You need to make sure to set the solution settings so that the library is compiled first and then the test application. If you have any questions about how to do this or anything else, just respond here and I will do my best to try and answer them. I am still figuring this all out myself, so I might not have all the answers, but am willing to help if I can. Good luck.

28 Aug 2014, 03:05
James Grenning (190 posts)


This is probably worth a blog post, or more. I think you get this now, but let me say it anyway.

Production code goes into a library. During linking, object files from the library are included in the build if they satisfy any unresolved external references.

In gcc with CppUTest, lets you control this by specifying the production code in these symbols: # SRC_DIRS - Directories containing source file to built into the library # SRC_FILES - Specific source files to build into library. Helpful when not all code # in a directory can be built for test (hopefully a temporary situation)

Like Richard said, in VS put the production code into a static lib project.

Test code and test doubles can override production code when it is explicitly included in the build.

In gcc with CppUTest, # TEST_SRC_DIRS - Directories containing unit test code build into the unit test runner # These do not go in a library. They are explicitly included in the test runner # TEST_SRC_FILES - Specific source files to build into the unit test runner # These do not go in a library. They are explicitly included in the test runner # MOCKS_SRC_DIRS - Directories containing mock source files to build into the test runner # These do not go in a library. They are explicitly included in the test runner in VS, like Richard said, put test code into the console app, or a library that is searched before the production code library.

(the commented lines are from

Hope that helps a bit.

You must be logged in to comment