Nous avons déjà compris le fonctionnement de PHPUnit et le principe des tests en développement PHP, au travers de l'article fr Développement piloté par les tests avec PHPUnit. Nous allons à présent montrer les fonctionnalités avancées de PHPUnit notamment concernant les patterns de tests, Mock, Stub, Double, Spy ; nous verrons comment les mettre en place au travers d'un exemple simple et concret, et en quoi ces techniques peuvent rapidement devenir addictives. Pour cela, il conviendra de rappeler les grands principes du développement logiciel orienté objet : SOLID.
Nous parlerons ensuite d'autres fonctionnalités PHPUnit propres au contexte des tests : sauvegarde des variables globales, sauvegarde du contexte statique, isolation des tests dans des processus distincts...

Les tests, au même titre que la documentation, font parti du code. Un code fouilli est difficilement testable. Un code testable est un code maintenable.
Tester son code permet de mieux appréhender le changement de spécifications et de valider le bon fonctionnement d'un algorithme.

Ce billet a pour objectif d'illustrer, à l'aide d'un exemple assez complet et proche de cas réels, la mise en place des tests transactionnels pour l'ensemble des couches applicatives.
Il aborde JUnit4 enrichi avec les annotations de Spring 2.5+ et ses lanceurs pour exécuter facilement les tests.

Création d'un jeux de données le plus réaliste possible pour un test de charge avec Benerator.

Cet article donne quelques pistes de réflexion pour faciliter les tests dans le cadre d'une méthode de développement "cycle en V".

Cet article va vous présenter l'utilisation de Easymock et de JUnit 4 pour effectuer des tests unitaires avec des simulacres de tests.

Ce tutoriel a pour objectif de mettre en pratique le développement dirigé par les tests en construisant une petite application web. Du fait de sa taille conséquente, il sera mis à jour régulièrement.

Ce tutoriel a pour objectif de mettre en pratique le développement dirigé par les tests en construisant une petite application web. Du fait de sa taille conséquente, il sera mis à jour régulièrement.

Les tests, au même titre que la documentation, font parti du code. Un code fouilli est difficilement testable. Un code testable est un code maintenable.
Tester son code permet de mieux appréhender le changement de spécifications et de valider le bon fonctionnement d'un algorithme.

Cet article décrit plusieurs exemples de tests unitaires qui exploitent un principe de vérification d'invariances.

Dans cet article, on va voir comment on peut, en utilisant un Framework dédié, fournir un moyen de tester l'interaction entre les objets de notre code, ou même entre nos objets et des entités extérieures au code, telles que des bases de données ou le système.

La gestion des exigences dirigée par les tests, ou Test-Driven Requirements (TDR), représente l'étape ultime dans l'adoption d'un processus de développement dit « lean ». L'article se propose de dresser un état de l'art du Test-Driven Requirements après avoir parcouru ses principes fondateurs que sont le Lean Software Development et le Test-Driven Development. Nous détaillerons différentes pratiques de TDR, telles que l'écriture de spécifications fonctionnelles testables avec des outils comme FIT, ou la génération de test basée sur l'interprétation de modèles comportementaux. La mise en oeuvre de ces pratiques sera illustrée par des retours d'expérience. Les impacts sur l'organisation et la redistribution des rôles seront également mis en lumière.

Le terme "objet simulacre" est devenu populaire pour décrire des objets spéciaux qui imitent de vrais objets dans le but de les tester. La plupart des environnements de développement ont maintenant des outils qui permettent de créer facilement des objets simulacres. Cependant, souvent on ne réalise pas que les objets simulacres sont un cas particulier d'objets de tests, qui permettent un style de test différent. Dans cet article j'explique comment les objets simulacres fonctionnent, comment ils encouragent le test basé sur la vérification du comportement, et comment la communauté autour d'eux les utilise pour développer un style de test différent.

Cette page propose une traduction des anti-patrons de tests unitaires recensés par James Carr sur son blog.

Mise en oeuvre de bouchons de tests avec Flex.

L'objectif de cet article est de présenter clairement, à travers des exemples simples, le framework de tests unitaires Java TestNG.

Ce tutoriel fournit une introduction aux tests unitaires PHP avec le framework de tests PHPUnit.

Cette page présente un tutoriel sur le développement dirigé par les tests (ou Test Driven Development en anglais). Le tutoriel présente les principes de cette méthode, et ensuite l'illustre pas à pas sur un exemple concret : la recherche de toutes les solutions du problème des pentaminos. Les principaux outils utilisés sont Visual C# Express et Nunit. Les notions de couverture de code, de complexité cyclomatique sont également abordées.

De l'intérêt de l'utilisation de framework de tests unitaires pour la constitution d'un code robuste : les principes, bonnes et mauvaises pratiques.
Exemple en Java.

Cet article a pour objectif de présenter ce qu'apporte JUnit4 pour les tests automatisés (annotations, nouvelles assertions, suppositions, tests paramétrés).

Présentation des patterns de tests pour des tests unitaires en Java

Régulièrement, les modèles et les données évoluent, impactant des changements sur les différentes réplications des bases, en développement, test, production, ...
Afin de garantir l'utilisation de données qui soient fidèles à la production, pour être dans un contexte similaire, dans ce tutoriel, nous allons générer des données pour une base de développement/recette à partir d'une base de production, tout en masquant les données jugées sensibles.
Pour cela, nous allons utiliser fr Change Manager 5.1, de la société fr Embarcadero, outil pour la gestion du changement des bases de données.

En Europe, grâce aux logiciels de tests nous pourrions économiser plus de 100 milliards d'euros par an.
Cet article revient sur quelques cas réels d'erreurs logicielles qui ont coûté très cher, et pose la problématique de l'intérêt des tests logiciels.
L'auteur finit par répertorier les différents types de tests qu'on retrouve classiquement dans l'industrie du logiciel, et qui contribuent chacun à l'amélioration de la qualité du logiciel et la réduction du risque d'erreurs.

JMockit est un framework de mocks pour les tests unitaires. En plus de proposer les fonctionnalités habituelles de mocking, il permet de poser des tests sur du code dit intestable. Absolument tout est mockable : les méthodes statiques, les initialiseurs statiques, les constructeurs et même les méthodes privées.

Faire des tests de charge réalistes n'est pas forcément évident pour de nombreuses raisons. Mais l'effort en vaut la peine car cela peut fausser les résultats s'ils ne sont pas réalistes. Dans cet article, nous verrons comment réaliser des tests de charges et comment éviter certains pièges.

"3T" est une version simplifiée des incontournables TDD (Test Driven Development), une méthode dans laquelle on commence par écrire des tests pour aider (guider) le développement des fonctionnalités. Ce second article sur le sujet propose une illustration de "3T" en action sous forme d'un miniroman.

Le pattern singleton est un des patterns les plus connus dans le génie logiciel. Fondamentalement, un singleton est une classe qui permet une seule instance d'elle-même, et habituellement donne un accès simple à cette instance. Le plus souvent, des singletons n'autorisent aucun paramètre lors de la création de l'instance - dans le cas contraire d'une seconde demande pour une instance mais avec un paramètre différent, cela pourrait s'avérer problématique ! (Si la même instance devait être accédée par toutes les demandes avec le même paramètre, le pattern factory est plus approprié.) Cet article traite seulement le cas où aucun paramètre n'est requis. Typiquement, un critère des singletons est qu'ils sont créés en différé - c'est-à-dire que l'instance n'est créée que lors de la première fois où on en a besoin.