Préparation des tests unitaires: Ce qui est important de garder à l'esprit lorsque l'on travaille sur une architecture logicielle? [fermé]

Question

Disons que je commence un nouveau projet, la qualité est une priorité absolue.

Je prévois de faire des tests approfondis de l'unité, ce qui est important de garder à l'esprit quand je travaille sur l'architecture pour faciliter et renforcer encore les tests unitaires?

modifier : J'ai lu un article il y a quelques temps (je ne trouve pas maintenant) parler de la façon dont le découplage Code instanciation des classes des comportements pourrait être être utile lors des tests unitaires. Voilà le genre de conseils de conception que je cherche ici.

Answer 1

Facilité d'essai vient par être en mesure de remplacer le plus grand nombre des dépendances de votre méthode a avec le code de test (objets fantaisie, faux, etc.) La façon actuellement recommandé d'y arriver est par inversion de dépendance, alias Hollywood Principe: « Don « t appelez-nous, nous allons vous appeler « . En d'autres termes, votre code devrait « demander des choses, ne cherchez pas les choses. »

Une fois que vous commencez à penser de cette façon, vous trouverez le code peut facilement avoir des dépendances sur beaucoup de choses. Non seulement vous avez des dépendances sur d'autres objets, mais les bases de données, les fichiers, les variables d'environnement, API OS, globals, singletons, etc. En adhérant à une bonne architecture, vous minimiser la plupart de ces dépendances en leur fournissant par les couches appropriées. Alors, quand vient le temps de tester, vous n'avez pas besoin d'une base de données de travail complète des données de test, vous pouvez simplement remplacer l'objet de données avec un objet de données fictives.

Cela signifie également que vous devez trier soigneusement votre projet de construction d'objets à partir de l'exécution de votre objet. La déclaration « nouveau » placé dans un constructeur génère une dépendance qui est très difficile à remplacer par une maquette de test. Il est préférable de passer ces dépendances via arguments du constructeur.

En outre, garder la loi de Déméter à l'esprit. Ne pas creuser plus d'une couche profonde dans un objet, ou bien vous créer des dépendances cachées. Appel Flintstones.Wilma.addChild (cailloux); signifie que ce que vous pensiez une dépendance à l'égard « Pierrafeu » est vraiment une dépendance à la fois « Pierrafeu » et « Wilma ».

Answer 2

Assurez-vous que votre code est testable en le rendant très cohérent, humble découplé. Et assurez-vous de savoir comment utiliser des outils pour se moquer de se moquer les dépendances lors de tests unitaires.

Je vous recommande de vous familiariser avec les SOLID, de sorte que vous peut écrire un code plus testable.

Answer 3

Vous pouvez également consulter ces deux SO questions:

• Adoption Test
• Qu'est-ce que devrait être une unité

Answer 4

Quelques pensées aléatoires:

• Définissez vos interfaces: découpler les modules fonctionnels les uns des autres, et de décider comment ils vont communiquer entre eux. L'interface est le « contrat » entre les développeurs de modules différents. Ensuite, si vos tests fonctionnent sur les interfaces, vous assurer que les équipes peuvent traiter les uns des autres de modules comme des boîtes noires, et donc travailler indépendamment.

• Construire et tester au moins la fonctionnalité de base de l'interface utilisateur d'abord. Une fois que votre projet peut « parler » à vous, il peut vous dire ce qui fonctionne et ce qui n'est pas ... mais seulement si ce n'est pas vous mentir. (Bonus:. Si vos développeurs ont pas d'autre choix que d'utiliser l'interface utilisateur, vous identifier rapidement les lacunes décelées dans la facilité d'utilisation, de flux de travail, etc )

• test au plus bas niveau pratique. vous êtes plus confiant que les petits morceaux de travail, le plus il sera facile de les combiner dans un ensemble de travail

• Ecrire au moins un test pour chaque fonction, sur la base des spécifications, avant de commencer à coder. Après tout, les caractéristiques sont la raison pour laquelle vos clients achèteront votre produit. Assurez-vous qu'il est conçu pour faire ce qu'il est censé faire!

• Ne soyez pas satisfait quand il fait ce qu'il est censé faire; assurer qu'il ne pas faire ce qu'il est pas censé faire! Nourrissez les mauvaises données, utiliser de manière illogique, débranchez le câble réseau pendant le transfert de données , exécutez-le à côté des applications contradictoires. Vos clients.

Bonne chance!

Answer 5

Vos tests ne jamais être aussi bon que vos besoins. Ils peuvent être les exigences que vous venez avec l'avant tout à la fois, ils peuvent être les exigences que vous venez avec un à la fois que vous ajoutez des fonctionnalités, ou ils peuvent être les exigences que vous venez avec une fois que vous expédiez et les gens commencent signaler un bateau chargé de bugs, mais vous ne pouvez pas écrire un bon test si personne ne peut ou documenter exactement ce que la chose est censé faire.