- Tests unitaires -

Nous désignerons par tests unitaires, les tests réalisés de façon séparée sur chacune des classes constituant le prototype. Ils permettent de vérifier le fonctionnement des méthodes au fur et à mesure de leur codage.

Pour chaque classe métier il faut vérifier qu'une méthode publique de type accesseur existe bien pour permettre la lecture des attributs privés ou protégés depuis les autres classes.

De façon à pouvoir tester les classes codées de façon cohérente, il est conseillé de coder en premier lieu les classes métiers et les classes d'interface, puis les classes d'IHM et enfin les classes techniques spécialisées telles que les classes représentant les états imprimés ou les fichiers locaux..

Les classes d'IHM seront codées dans l'ordre d'apparition des fenêtres ou des pages dans le SEF ou le SEP du prototype.

Les arbres d'héritage sont naturellement codés dans l'ordre descendant (classes d'interface, classes abstraites, super-classes puis sous-classes). Les autres classes sont codées en respectant l'ordre logique des relations qui les relient. De même, dans le cas d'une association ou d'une composition hiérarchique de type mère-fille, la classe mère sera codée avant la classe fille. En prenant l'exemple de la figure ci-dessous, la classe contrat (mère) sera codée avant la classe véhicule (fille).

Il est conseillé de coder les méthodes d'une classe dans l'ordre suivant : constructeur (ou "fabrique virtuelle" si l'on utilise ce design pattern), accesseurs, méthodes de classe, méthodes locales, et méthodes communicantes. Une méthode locale est une méthode qui ne fait appel à aucune méthode située dans une autre classe. Une méthode communicante appelle au moins une méthode d'une autre classe. Si le constructeur d'une classe doit faire appel à des données lues dans une base de données non encore développée, on simulera leur lecture en créant une classe technique provisoire qui renverra des données constantes au constructeur.

Nous allons illustrer la méthode avec le premier prototype du cas Assurance-Auto dont le diagramme des classes est rappelé à la figure ci-dessous. L'ordre de codage des classes pourrait être le suivant :

1 – TypeContrat
2 – Contrat
3 – Catégorie
4 – Véhicule
5 – Tarif
6 – FP_AssurAuto
7 – BD_TypesContrats ou BD_Catégories
8 – BD_Contrats
9 – BD_DétailContrat
10 – BD_DétailVéhicule
11 – BD_Paiement

La méthode affContrat() dans la classe Contrat permet d'afficher toutes les informations relatives à un contrat ainsi que les informations afférentes telles que le type de contrat. Or, nous remarquons que le libellé du type de contrat est un attribut privé qui ne peut être lu par la méthode affContrat(). Il est donc nécessaire de rajouter un accesseur, getType() à la classe TypeContrat qui en était démunie.