The term code coverage refers to the extent that the statements of a program are executed during a run. Thus, test coverage refers to code coverage when executing unit tests. This information can help you to do two things:
Check itself does not provide any means to determine this test coverage; rather, this is the job of the compiler and its related tools. In the case of gcc this information is easy to obtain, and other compilers should provide similar facilities.
Using gcc, first enable test coverage profiling when building your source by specifying the -fprofile-arcs and -ftest-coverage switches:
$ gcc -g -Wall -fprofile-arcs -ftest-coverage -o foo foo.c foo_check.c
You will see that an additional .gcno file is created for each .c input file. After running your tests the normal way, a .gcda file is created for each .gcno file. These contain the coverage data in a raw format. To combine this information and a source file into a more readable format you can use the gcov utility:
$ gcov foo.c
This will produce the file foo.c.gcov which looks like this:
-: 41: * object */
18: 42: if (ht->table[p] != NULL) {
-: 43: /* replaces the current entry */
#####: 44: ht->count--;
#####: 45: ht->size -= ht->table[p]->size +
#####: 46: sizeof(struct hashtable_entry);
As you can see this is an annotated source file with three columns: usage information, line numbers, and the original source. The usage information in the first column can either be '-', which means that this line does not contain code that could be executed; '#####', which means this line was never executed altough it does contain code—these are the lines that are probably most interesting for you; or a number, which indicates how often that line was executed.
This is of course only a very brief overview, but it should illustrate how determining test coverage generally works, and how it can help you. For more information or help with other compilers, please refer to the relevant manuals.