Building Unity
(The General Idea)
Your build process when you're building tests with Unity is a little different than when you build your release. For a release build, you're taking all of your source modules (and possibly other supporting libraries and whatnot) compiling each of them, linking them all together, and calling that your executable (we're talking high-level here. obviously the details can get more complex).
When you are Unit Testing, however, you're interested in a single source module at a time (the "unit" in unit testing). We're going to link that source module to a corresponding Test module (which is only part of this test build and is never part of your release). We're also going to link together a couple other basic things. One is Unity itself, obviously. Another likely candidate is a test runner, which is basically a "main" function. You can maintain your own "main" function in your test file manually, or you can use Unity's helper scripts generate one for you. The latter obviously keeps you from making mistakes, but requires a bit more configuration.
Borrowing a page from our own class, it could look something like this:
In this case, we are testing the module B. Along with B, we pull in TestB, unity, and whatever header files are required by these C files. That's it. The source modules A, C, and D are ignored for this test. This test is compiled, linked, executed, and the results are collected. Then the build system is ready to move on to the next step. It should repeat this process for any module that has a Test[blah].c file for it. To be really handy, a build system should summarize the failures (and probably the ignores) at the end.
That's the basic concept!
If you're willing to get a little more complex, then you add in automated test runners (your build system needs to remember to trigger generation of that test runner whenever the test file changes) and mocks (if you're using CMock, your build system will need to track what files are required for each test and build / link the appropriate mock versions).
But we'll leave those complex details for another page.
Now that you understand the basic build process. How might we implement it using different build tools?