Et pour faire plaisir à 0²:
http://wwwis.win.tue.nl/2R690/doc/ECSS-E-ST-40C(6March2009).pdf (clause 5.5.3.2 + annexe K (principalement chapitres 8sqq)).

Ensuite pour répondre à la question, dans mes projets les tests unitaires font normalement partie du projet lui-même et sont dans des dossiers "Tests" contenus dans chaque dossiers de chaque module intégré à l'arborescence du projet. J'ai un serveur d'intégration continue (en l'occurrence Jenkins) qui s'occupe de compiler et d'exécuter tous les tests à chaque commit (rien de bien original).
Pour les frameworks, j'ai des petits projets en C avec simplement "Check" ( http://check.sourceforge.net/doc/check_html/ ), et de plus gros trucs qui utilisent Cantata (qui n'est pas exactement gratuit).

À mon sens, le test unitaire a trois principales utilités:
- Vérifier que le code est conforme aux exigences (ces exigences pouvant être testées au niveau du projet entier, ou au niveau unitaire justement, et comme je disais, si on ne sait pas ce que le programme doit faire il est difficile de le tester),
- Vérifier la stabilité du code (en testant automatiquement des valeurs critiques (par exemple 0, NULL, etc.), les valeurs limites, etc.),
- Vérifier qu'une modification dans un module n'a pas d'effets de bords ailleurs (tests de non-régression).
En bonus, tu peux coupler tes tests unitaires avec les tests de couverture (dans le cas de Check, on peut directement utiliser gcov) pour voir quelle proportion de ton code tu testes (en gros ça va lister toutes les lignes de code exécutées), et détecter par exemple du code mort.

Comme dit Flanker, les tests unitaires, comme leur nom l'indiquent, ciblent des petites portions de code (typiquement des fonctions seules, en stubbant les appels qu'elles font). Pour tester un fonctionnement plus complexe (plusieurs fonctions, classes ou modules interagissant), on parle plutôt de tests d'intégration ou de tests système. Le concept reste le même à plus haut niveau mais ils demandent souvent une infrastructure plus complexe, voire dédiée.