Before trying to write the tests, we should examine the documentation to find out what is to be tested. Here we suppose that the targets of the tests are functions – the public API of some library.

The functions to be tested should be split into functional groups. Sometimes such grouping is already done in the documentation. For instance, GLib Reference Manual is divided into a number of sections such as “Memory Allocation”, “String Utility Functions”, “Key-value file parser”, etc. The functions described in each section form a functional group in this case.

The groups of functions should not be very large. In practice, if a group contains more than 10–15 functions, it probably should be split into smaller groups.

Often, to properly test the functions from one group, we need the functions from one or more other groups. This way the former group becomes dependent on the latter ones.

Ideally, the functional groups should have no cyclic dependencies between each other. Assume group “A” depends on group “B” (that is, the functions from “B” are necessary to test the functions from “A”). If “B” also depends on “C” while “C” depends on “A” (or even “B” itself depends on “A”), it is a cyclic dependency. Situations like this should be avoided.