Mon interprétation de cet exposé est:
- tester les composants, pas les classes.
- tester les composants via leurs ports d'interface.
Ce n'est pas indiqué dans l'exposé, mais je pense que le contexte supposé des conseils est quelque chose comme:
- vous développez un système pour les utilisateurs, pas, disons, une bibliothèque ou un cadre utilitaire.
- l'objectif des tests est de livrer avec succès autant que possible dans un budget compétitif.
- les composants sont écrits dans un langage unique, mature, probablement de type statique, comme C # / Java.
- un composant est de l'ordre de 10 000 à 5 000 lignes; un projet Maven ou VS, un plugin OSGI, etc.
- les composants sont écrits par un seul développeur ou par une équipe étroitement intégrée.
- vous suivez la terminologie et l'approche de quelque chose comme l' architecture hexagonale
- un port de composant est l'endroit où vous quittez la langue locale, et son système de type, derrière, en passant à http / SQL / XML / bytes / ...
- enveloppant chaque port sont des interfaces typées, au sens Java / C #, qui peuvent avoir des implémentations commutées pour changer de technologie.
Ainsi, tester un composant est la plus grande étendue possible dans laquelle quelque chose peut encore être raisonnablement appelé test unitaire. C'est assez différent de la façon dont certaines personnes, en particulier les universitaires, utilisent le terme. Cela ne ressemble en rien aux exemples du didacticiel type d'outil de test unitaire. Il correspond cependant à son origine dans les tests matériels; les cartes et modules sont testés à l'unité, pas les fils et les vis. Ou du moins vous ne construisez pas un faux Boeing pour tester une vis ...
Extrapoler à partir de cela, et jeter certaines de mes propres pensées,
- Chaque interface sera soit une entrée, une sortie ou un collaborateur (comme une base de données).
- vous testez les interfaces d'entrée; appeler les méthodes, affirmer les valeurs de retour.
- vous vous moquez des interfaces de sortie; vérifier que les méthodes attendues sont appelées pour un cas de test donné.
- vous simulez les collaborateurs; fournir une mise en œuvre simple mais fonctionnelle
Si vous le faites correctement et proprement, vous avez à peine besoin d'un outil moqueur; il n'est utilisé que quelques fois par système.
Une base de données est généralement un collaborateur, elle est donc falsifiée plutôt que raillée. Ce serait pénible à mettre en œuvre à la main; heureusement, de telles choses existent déjà .
Le modèle de test de base consiste à effectuer une séquence d'opérations (par exemple, enregistrer et recharger un document); confirmez que cela fonctionne. C'est la même chose que pour tout autre scénario de test; aucun changement d'implémentation (fonctionnel) n'est susceptible d'entraîner l'échec d'un tel test.
L'exception est où les enregistrements de la base de données sont écrits mais jamais lus par le système testé; par exemple, les journaux d'audit ou similaires. Ce sont des sorties et doivent donc être moquées. Le modèle de test consiste à effectuer une séquence d'opérations; confirmer que l'interface d'audit a été appelée avec les méthodes et les arguments spécifiés.
Notez que même ici, à condition que vous utilisiez un outil de simulation de type sécurisé comme mockito , renommer une méthode d'interface ne peut pas entraîner un échec de test. Si vous utilisez un IDE avec les tests chargés, il sera refactorisé avec la méthode renommer. Si vous ne le faites pas, le test ne sera pas compilé.