Share
L'idée principale de TDD (Test-Driven Development) est d'écrire des tests avant d'écrire un code fonctionnel, puis d'écrire le moins de code possible pour réussir les tests. Cela peut sembler étrange de développer de cette façon, mais c'est en fait très utile, car la base de test sert également de spécification partielle du code principal..
Compte tenu de cette prémisse aussi simple, il existe une quantité incroyable de terminologie et de techniques. Dans cet article, je résume les termes et mots à la mode les plus importants que vous pourriez entendre et les définit..
La programmation test-first permet des tests fonctionnels de haut niveau.
Le niveau de test le plus élevé confirme que le logiciel répond aux exigences du client. Les tests d'acceptation sont généralement exécutés dans des environnements aussi proches que possible de la production. Voir test fonctionnel et test système.
Les assertions sont des instructions qui effectuent une vérification réelle de la sortie du logiciel. En général, une seule fonction appelée affirmer est suffisant pour exprimer un chèque. En pratique, les bibliothèques de tests disposent souvent de nombreuses fonctions d’affirmation pour répondre à des besoins spécifiques (tels que affirmer, AssertEqual et plus) pour offrir une meilleure analyse et une sortie plus conviviale.
Une technique de test qui incorpore les doublons de test au logiciel, affirmant qu'il appelle les méthodes correctes dans un ordre correct. Voir mock pour un exemple. Voir aussi les tests d'état.
Un sous-ensemble de TDD motivé par le besoin d'une communication plus claire et d'une documentation appropriée. BDD est peut-être le plus grand développement récent du TDD.
Son idée principale est de remplacer une terminologie confuse et centrée sur le développeur (tests, des suites, des affirmations etc) avec langue omniprésente que tous les intervenants participants (y compris le personnel non technique et, éventuellement, les clients) puissent comprendre.
Voir la user story.
Un principe général dans les tests où la personne qui écrit les tests ne connaît pas ou évite les éléments internes du logiciel, choisissant plutôt de tester l'interface publique du logiciel strictement par son interface ou ses spécifications. Voir les tests de la boîte blanche.
Une stratégie pour rédiger des tests afin d’attraper les erreurs de ce type et d’autres types d’erreurs similaires. Pour effectuer un test de valeur limite, testez les entrées autour de certaines limites éventuellement problématiques. En cas de nombre entier, cela pourrait être 0, -1, MIN_INT, MAX_INT et d'autres valeurs similaires.
Les assertions sont des instructions qui effectuent une vérification réelle de la sortie du logiciel..
Un mannequin est un type de double test qui n’est jamais utilisé par le logiciel lui-même, mais est uniquement utilisé dans des tests pour renseigner les paramètres requis..
Les faux sont des doubles de test qui implémentent les fonctionnalités requises d'une manière utile pour les tests, mais qui les empêchent également d'être utilisés dans un environnement de production. Par exemple, une base de données clé-valeur qui stocke toutes les valeurs en mémoire et les perd après chaque exécution permet potentiellement aux tests de s'exécuter plus rapidement, mais sa tendance à détruire les données ne lui permettrait pas d'être utilisées en production..
Un environnement particulier qui doit être configuré avant qu'un test puisse être exécuté. Cela consiste généralement à configurer tous les doublons de test et autres dépendances du logiciel testé: telles que l'insertion de données prédéfinies dans une fausse base de données, la configuration de certaines structures de répertoires dans le faux système de fichiers, la définition de propriétés des dépendances du logiciel testé.
Une activité de test de haut niveau vérifiant que toutes les exigences commerciales du produit sont satisfaites. Les tests fonctionnels impliquent généralement l'utilisation d'histoires d'utilisateurs pour cibler un niveau d'exigences supérieur afin de couvrir autant de scénarios d'utilisation que possible. Voir les tests d'acceptation et les tests du système. Par exemple:
# Dans cet exemple, nous vérifions que la page à propos du site Web fonctionne comme prévu. Ouvrez 'exemple.com', cliquez sur 'on' à propos de nous 'assertThereIs' Nous sommes une petite entreprise exemple '
Un langage familier pour une collection de tests réussie, ou parfois un test de réussite particulier. Voir rouge.
Une activité de test de niveau intermédiaire qui vérifie qu'un certain ensemble de modules fonctionne correctement ensemble. Les tests d'intégration sont comme des tests unitaires sans utilisation de doublons de test pour un certain sous-ensemble de dépendances, testant essentiellement les interactions entre les dépendances du logiciel. Exemple:
Accentsconagua
# Dans cet exemple, nous vérifions que l'utilisateur nouvellement enregistré, # qui a été référé par un autre utilisateur, obtient une "amitié" sur le site. # Nous vérifions ici l’interaction entre le contrôleur de formulaire, la base de données # et un enregistrement utilisateur actif db = new Fake Db u1 = db.createUser (name = 'john') RegistrationForm (db, name = "kate", référencé = "john ") .save () assert (u1.hasFriend ('kate')) Un type de double test créé pour un test ou un cas de test particulier. Il s'attend à être appelé un nombre spécifique de fois et donne une réponse prédéfinie. À la fin du test, une simulation génère une erreur si elle n'a pas été appelée autant de fois que prévu. Une maquette avec des attentes strictes fait partie du cadre des assertions. Exemple:
# Dans cet exemple, nous utilisons une base de données fictive pour vérifier que le formulaire # utilise la base de données pour stocker le nouvel utilisateur. # Si la base de données n'a pas été appelée à la fin du test, # la maquette elle-même déclenchera une erreur d'assertion. db = new Mock Db db.expect ('save'). once (). avec (name = 'john') RegistrationForm (db, name = "john"). save () Un moyen d'étendre et de changer le comportement d'objets et de classes existants dans un langage de programmation. Monkey-patching peut être utilisé comme alternative à l'injection de dépendance et aux doublons de test en modifiant directement les fonctions existantes appelées par le logiciel testé (et en les replaçant après le test)..
# Dans cet exemple, nous remplaçons la fonction de bibliothèque standard # pour empêcher le test d'utiliser un système de fichiers réel fileystem.listdir = f (nom) -> ['.', '…', 'Foo', 'bar']; assertEqual (MyFileSearch ('foo'). count (), 1) Un langage familier pour une collection de tests ayant échoué ou parfois un test particulier ayant échoué. Voir le vert.
Processus d'amélioration des détails d'implémentation du code sans modifier ses fonctionnalités.
La refactorisation sans tests est un processus très fragile, car le développeur effectuant la refactorisation ne peut jamais être sûr que ses améliorations ne casseront pas certaines fonctionnalités..
Si le code a été écrit à l'aide d'un développement piloté par les tests, le développeur peut être sûr que son refactoring a réussi dès que tous les tests ont réussi, car toutes les fonctionnalités requises du code sont toujours correctes..
Défaut logiciel apparaissant dans une fonctionnalité particulière après un événement (généralement une modification du code).
Test de scénario
Voir les tests fonctionnels.
Un processus de préparation d'un montage. Voir démontage. Exemple:
# Dans cet exemple, nous préparons une fausse base de données avec certaines fausses valeurs # dont nous aurons besoin pour plusieurs tests db = new Fb Db db.createUser (name = 'john') db.createUser (name = 'kate') db.createFriendship ( 'john', 'kate')
Une forme de test unitaire lorsque le code de test fournit un test double et affirme que l'état de ces doubles a été modifié de manière correcte. Voir les tests de comportement.
# Dans cet exemple, comme dans l'exemple sur les objets fantaisie #, nous vérifierons que le formulaire utilise la base de données pour stocker le nouvel utilisateur. # Cette fois, nous allons vérifier l'état plutôt que le comportement db = new Fake Db RegistrationForm (db, name = "john"). Save () assertInList ('john', db.listUsers ()) Les faux sont des doubles de test qui ne sont jamais utilisés par le logiciel actuel.
Un type de test double pouvant répondre au logiciel testé avec des réponses prédéfinies. Contrairement aux simulacres, toutefois, les stubs ne vérifient généralement pas s'ils ont été appelés correctement, mais s'assurent simplement que le logiciel peut appeler ses dépendances..
Une activité de test de haut niveau lorsque l'intégralité du logiciel est testée de haut en bas. Cela inclut des tests fonctionnels, ainsi que la vérification d'autres caractéristiques (telles que la performance et la stabilité).
Une abréviation pour logiciel sous test. Utilisé pour distinguer le logiciel testé de ses dépendances.
Un processus de nettoyage d'un appareil. Dans les langages récupérés, cette fonctionnalité est généralement gérée automatiquement. Voir la configuration.
La plus petite vérification possible pour l'exactitude. Par exemple, un seul test pour un formulaire Web peut consister à vérifier que, lorsqu'il reçoit une adresse électronique invalide, le formulaire avertit l'utilisateur et suggère un correctif. Voir cas de test.
Une collection de tests regroupés par un attribut. Par exemple, un scénario de test pour un formulaire Web peut être un ensemble de tests vérifiant le comportement du formulaire pour différentes entrées valides et non valides..
function t1: assertNoError (RegistrationForm (name = 'john', mot de passe = "agrafe de la batterie du cheval correcte"). save ()) t2: assertError (MissingPassword, RegistrationForm (name = 'john'). save ()) function t3: assertError (StupidPassword, RegistrationForm (name = 'john', password = "password"). save ())
Les user stories sont généralement définies en langage humain pour se concentrer sur l'expérience utilisateur.
Tout type de métrique qui tente d'estimer la probabilité d'un comportement important du SUT non encore couvert par les tests. Les techniques les plus populaires incluent différents types de couverture de code: techniques permettant de s'assurer que toutes les instructions de code possibles (ou fonctions ou branches logiques dans le code) ont été exécutées pendant les tests.
Un processus de développement TDD. Étant donné que le développement de TDD commence par l'écriture de quelques tests, il est clair que la suite de tests démarre en rouge. Dès que le développeur implémente toutes les fonctionnalités récemment testées, les tests deviennent verts. Maintenant, le développeur peut refactoriser son implémentation en toute sécurité sans risquer d’introduire de nouveaux bogues, car il dispose d’une suite de tests. Une fois le refactoring terminé, le développeur peut recommencer le cycle en écrivant plus de tests pour plus de nouvelles fonctionnalités. Ainsi, le cycle d'essai rouge-vert-refactor.
Test Double
Les doubles de test sont des objets créés par le code de test et transmis au SUT pour remplacer les dépendances réelles. Par exemple, les tests unitaires doivent être très rapides et ne tester qu'un logiciel particulier.
Pour ces raisons, ses dépendances, telles que des bibliothèques d'interaction de base de données ou de système de fichiers, sont généralement remplacées par des objets agissant en mémoire au lieu de communiquer avec une base de données ou un système de fichiers réel..
Il existe quatre grandes catégories de doubles d’essais: les mannequins, les faux, les talons et les faux.
Une collection de cas de test qui testent une grande partie du logiciel. Alternativement, tous les cas de test pour un logiciel particulier.
Le test de la boîte blanche permet une analyse plus approfondie des problèmes possibles dans le code.
La programmation test-first est un terme légèrement plus large pour le développement piloté par les tests. Alors que TDD favorise un couplage étroit entre les tests d'écriture (généralement des tests unitaires) et l'écriture du code, la programmation test-first permet à la place des tests fonctionnels de haut niveau. Cependant, la distinction dans l’usage général est rarement notée, et deux termes sont généralement utilisés indifféremment..
La technique de test de niveau le plus bas consistant en des cas de test pour les unités de code les plus petites possibles. Un test unitaire unique ne vérifie généralement qu'un petit comportement particulier et un scénario de test unitaire couvre généralement toutes les fonctionnalités d'une fonction ou d'une classe donnée..
Une description unique d'un groupe particulier de personnes désirant effectuer une tâche particulière en utilisant le SUT pour atteindre un objectif particulier. Les user stories sont généralement définies dans des langages humains et utilisent des termes simples, centrés sur l'utilisateur, pour éviter de prendre en compte les détails de la mise en œuvre et de se concentrer sur l'expérience utilisateur. Par exemple:
En tant qu'utilisateur, je souhaite pouvoir rechercher mes amis sur ce site à l'aide de mon carnet d'adresses au lieu de les rechercher un par un, car cela me fera gagner beaucoup de temps..
Le test de la boîte blanche est une technique de test lorsqu'une personne effectuant le test connaît ou peut lire les éléments internes du SUT. Contrairement aux tests de boîte noire plus courants, les tests de boîte blanche permettent une analyse plus approfondie des problèmes possibles dans le code..
Par exemple, une valeur limite particulière peut ne pas ressembler à une valeur basée uniquement sur la spécification du logiciel, mais sa mise en œuvre peut être évidente..
En outre, toutes les techniques de couverture d’essais font, par définition, partie des essais en boîte blanche..
