> I have written test skeletons for the 22 functions :-) but now I'm wondering how > to actually test each one in a separated way. For example pdf_list_add_first() > returns a pdf_list_node_t which I can't rely on until I know it has the correct > value in it by using pdf_list_node_value (node), but then I should check > pdf_list_node_value() first, and I can't until I add at least one element to the > list, calling pdf_list_add_first(). Voila a damn testing cycle. How should I > deal with that ?
I guess it's not a big problem, as long as you also have specific tests for those functions that you are using. My suggestion would be to directly forget the problem: when you are testing pdf_list_add_first(), just assume that all the other functions that you are using are already validated with unit tests, even if the tests are run afterwards; and focus only in checking if pdf_list_add_first() is ok. I agree with that approach. Unit tests should be concrete and concentrate in the functionality of a single function.
