Bah tu découpes, jusqu'à ce que tu sois persuadé que chaque fonction a une couverture qui te parrait raisonnable. Certains exigent une couverture des lignes de 100% par exemple. d'autres demandent juste que chaque fonction soit appellée. C'est à toi de voir.
Le seul truc, c'est que ça exige souvent d'arriver à un niveau assez bas. Le découpage en module te permet de simplifier un peu les choses en terme de groupage des tests, mais influe peu sur le découpage en lui-même en théorie. Par contre, vu que tu fais du réseau via RAS, il va te falloir quelques sérieuses classes bouchons pour simuler l'établissement de la connexion (simuler le comportement de Windows dans des cas positifs, comme négatifs).
A priori, sépare les unit-tests de tes tests d'intégration. Les tests unitaires, c'est une bonne habitude de faire en sorte qu'ils ne dépendent de rien d'autre d'externe (donc pas de connexion RAS, pas de serveur FTP, etc). On doit pouvoir les exécuter sur n'importe quelle machine, à n'importe quel moment.
A l'inverse, les tests d'intégration peuvent exiger un peu plus . L'intégration, c'est ce qui lie les modules ensembles: par exemple, tester que l'établissement d'une session FTP via RAS fonctionne.
Donc, en gros, les tests unitaires:
- tester que RAS énumère correctement le contenu des connexions dispos, et que le numéro que tu appelles est bien celui auquel tu t'attends. Tester via une classe bouchon que si le modem est éteint, le comportement correct est généré.
Tests intégrations:
- vérifier que toute la connexion se passe bien, et que les messages d'erreurs retournés en cas de problèmes sont les bons, en composant un numéro à la con par exemple.
- tester la connexion FTP contre un serveur local à la machine de test.
