Not sure where to start? Maybe this can help! This is a little invention that Dr. Surly came up with. Answer the following questions, and then follow the links. This should help you decide which tools are right for you and lead you to help on getting them installed!
Q1. Build System
First, let's figure out how you feel about your overall needs for a build system. If we walk you through how this all works, and gave you some handy examples, would you be comfortable setting up your own build system?
A. My release build is fairly straightforward or typical.
B. My release build is complicated because it has many subprojects, custom libraries, or dependencies.
C. My release build is complicated because it has multiple tool dependencies
D. My release build is complicated because it has many conditional build options
E. I prefer to avoid using "extra" tools like scripting languages and whatnot.
F. I really like full control over my builds and don't want any mysterious "magic"
The first question concerns your release build system. Yes, we're going to be setting up a TEST build system, but complexity in your releases often drives complexity in your tests.
We've given you a lot of options, but really your answer here drives a fairly simple decision point.
If you feel like your best answer fits any of options A through C, your best option is probably to install Ceedling. Ceedling provides a straightforward interface for configuring basic to complicated project structures. It supports extra build steps and most situations that make a build "tricky". If this is you, read about Ceedling then skip ahead to Q4.
Building Your Own
So when would you build your own? Well, the remaining options of D through F are good indicators that you might want to build your own system. Either you have a strong desire to keep your toolchain typical (like make or cmake or whatnot) or you feel your release is so complicated that a standard tool isn't going to be able to hack it. If this is you, move on to Q2.
Question 2 is guiding us to choose if we need to install CMock or not. You can test many many modules with just Unity. You can even create your own stubs and fakes to do some interaction testing on your own. Creating your own, however, takes a lot of time, particularly when CMock can often just do it for you.
If you feel like you fit into C or D, you're going to want to install CMock. The awesome news is that Unity will automatically be downloaded as part of it. CMock is going to boost your unit testing game by automatically generating some test code for you by pointing it at header files. Why don't you go ahead and read about CMock, install it, and then move on to Q3.
Unity is our core testing framework for C. It's written in C, for C developers. It specializes in embedded use, but can be used for other C projects too. It has a few options Ruby scripts, but you can ignores those as needed. Why don't you learn about Unity, install it, and then move on to Q3.
Q2. Unit Testing Style
You can do State-Based Testing with any of our tools. Unless you're willing to do a lot of extra work on your own, Interaction Testing requires tool support. What kind of testing do you expect to do?
A. I just want basic unit testing
B. Didn't I already mention I don't want to use extra tools?
C. I want to automatically generate mocks and stubs for interaction testing.
D. I don't really understand but want to keep my options open.
Really, if you're going to put together your own build process, you should build it out of whatever build tool YOU are most comfortable with. That being said, here are some notes on tools that we've personally used.
We've reached the final step. This is where you need to do a bit of research, most likely. It's time to figure out what your best option is for actually RUNNING your tests. You can read the overview or this helpful article on which is best for you, then make your decision and follow the links for some advice on configuration.