Tests unitaires pratiques avec Java et JUnit
 |
Description
Introduction au livre
Andy Hunt et Dave Thomas de The Pragmatic Programmer expliquent :
Tests unitaires pragmatiques !
Les tests unitaires, piliers d'un code propre : par où commencer ? Ce livre explique les fondamentaux des tests unitaires : concept, raisons d'écrire des tests unitaires, bonnes pratiques, utilisation d'objets simulés, tests unitaires automatisés et refactoring.
De plus, sa structure vous permet de pratiquer les tests unitaires étape par étape avec Java et JUnit.
Recommandé aux personnes qui débutent dans le domaine des tests unitaires ou qui souhaitent approfondir leurs connaissances en la matière.
Tests unitaires pragmatiques !
Les tests unitaires, piliers d'un code propre : par où commencer ? Ce livre explique les fondamentaux des tests unitaires : concept, raisons d'écrire des tests unitaires, bonnes pratiques, utilisation d'objets simulés, tests unitaires automatisés et refactoring.
De plus, sa structure vous permet de pratiquer les tests unitaires étape par étape avec Java et JUnit.
Recommandé aux personnes qui débutent dans le domaine des tests unitaires ou qui souhaitent approfondir leurs connaissances en la matière.
- Vous pouvez consulter un aperçu du contenu du livre.
Aperçu
indice
Partie 1 : Principes fondamentaux des tests unitaires
Chapitre 1 : Créer votre premier test JUnit
1.1 Pourquoi écrire des tests unitaires ?
1.2 Notions de base de JUnit : Réussir son premier test
__1.2.1 Paramètres du projet
1.2.2 Comprendre un peu mieux les tests JUnit
__1.2.3 Exécution de JUnit
1.3 Préparation, exécution et validation des tests
1.4 Les tests testent-ils vraiment quelque chose ?
1.5 En conclusion
Chapitre 2 : Utiliser JUnit en conditions réelles
2.1 Compréhension du sujet testé : Classe de profil
2.2 Déterminez les tests que vous pouvez rédiger
2.3 Couverture à chemin unique
2.4 Création d'un deuxième test
2.5 Initialisation des tests avec la méthode @Before
2.6 Et maintenant ?
2.7 En conclusion
Chapitre 3 : Approfondissement des assertions JUnit
3.1 Assertions JUnit
__3.1.1 assertTrue
__3.1.2 assertThat compare une valeur spécifique
3.1.3 Examen de l'important comparateur Hamcrest
3.1.4 Comparaison de deux nombres à virgule flottante
__3.1.5 Explication de l'assertion
3.2 Trois façons d'anticiper les exceptions
3.2.1 La méthode simple : utiliser des annotations
3.2.2 L'ancienne méthode : try/catch et échec
3.2.3 Nouvelle méthode : règle ExpectedException
3.2.4 Ignorer les exceptions
3.3 En conclusion
Chapitre 4 Organisation du test
4.1 Maintien de la cohérence des tests avec AAA
4.2 Tests comportementaux vs. tests de méthode
4.3 Relation entre les tests et le code de production
4.3.1 Séparation du code de test et du code de production
4.3.2 Exposition aux données internes vs. exposition aux comportements internes
4.4 La valeur des tests ciblés à objectif unique
4.5 Les tests comme documentation
4.5.1 Documenter les tests avec des noms cohérents
4.5.2 Donner du sens aux tests
4.6 En savoir plus sur @Before et @After (initialisation et nettoyage communs)
4.6.1 Annotations BeforeClass et AfterClass
4.7 Le vert, c'est bien : garder les tests pertinents
4.7.1 Tests plus rapides
__4.7.2 Tests exclus
4.8 En conclusion
Partie 2 : Acquisition de techniques de mémorisation rapide
Chapitre 5 : Les PREMIERS attributs d’un bon test
5.1 PREMIÈRE ÉTAPE : Bonnes conditions de test
5.2 [F]PREMIER : Rapide
5.3 PREMIÈRE ÉTAPE : Isoler
5.4 PREMIER : Les bons tests doivent être reproductibles.
5.5 PREMIER : Auto-vérifiable
5.6 FIRS[T] : À utiliser au bon moment
5.7 En conclusion
Chapitre 6 - BICEPS droit : Que tester ?
6.1 [Droit]-BICEP : Les résultats sont-ils corrects ?
6.2 Droite-[B]ICEP : Les conditions aux limites sont-elles correctes ?
6.3 N'oubliez pas que les conditions aux limites sont CORRECTES
6.4 Right-B[I]CEP : Peut-on tester la relation inverse ?
6.5 Right-BI[C]EP : La vérification croisée peut-elle être effectuée par d'autres moyens ?
6.6 Right-BIC[E]P : Peut-on forcer une condition d'erreur à se produire ?
6.7 Right-BICE[P] : Les conditions de performance répondent-elles aux normes ?
6.8 En conclusion
Chapitre 7 Conditions aux limites : Mnémonique CORRECTE
7.1 [C]ORRECT : [C]onformité
7.2 CORRECT : Commande
7.3 CO[R]RECT : [R]ange(range)
__7.3.1 Création d'un comparateur personnalisé qui vérifie l'invariance
7.3.2 Tests de plage en intégrant des méthodes immuables
7.4 CORRECT : Référence
7.5 CORR[E]CT : [E]n existence
7.6 CORRE[C]T : [C]ardinité
7.7 CORREC[T]: [T]ime(temps)
7.8 En conclusion
Partie 3 : La vision d'ensemble du projet
Chapitre 8 : Refactorisation vers un code propre
8.1 Refactorisation mineure
8.1.1 Opportunités de refactorisation
8.1.2 Méthodes d'extraction : votre deuxième allié le plus précieux en matière de refactorisation
8.2 Trouver un meilleur foyer pour les méthodes
8.3 Refactorisation automatique et manuelle
8.4 Refactorisation excessive ?
8.4.1 Récompenses : Unités claires et testables
8.4.2 Problèmes de performance : Ne soyez pas
8.5 En conclusion
Chapitre 9 : Problèmes de conception plus importants
9.1 Classes de profils et SRP
9.2 Extraction d'une nouvelle classe
9.3 Séparation des commandes et des requêtes
9.4 Coûts de maintenance des tests unitaires
__9.4.1 Comment se protéger
__9.4.2 Correction des tests défectueux
9.5 Réflexions sur d'autres modèles
9.6 En conclusion
Chapitre 10 Utilisation de l'objet Cou
10.1 Défis des tests
10.2 Remplacement des actions complexes par des ébauches
10.3 Modifications de conception pour faciliter les tests
10.4 Ajouter de l'intelligence aux ébauches : validation des arguments
10.5 Simplifier les tests à l'aide de l'outil de simulation
10.6 Une dernière simplification : présentation de l’outil d’injection
10.7 Ce qui est important pour bien utiliser son cou
10.8 En conclusion
Chapitre 11 : Refactorisation des tests
11.1 Comprendre la recherche
11.2 Tests suspects : Code de test inutile
11.3 Défauts de test : Absence d’abstraction
11.4 Test olfactif : Informations inappropriées
11.5 Test olfactif : Puffy Creation
11.6 Test olfactif : Affirmations multiples
11.7 Tests olfactifs : détails non pertinents pour les tests
11.8 Test d'odeur : Mauvaise organisation
11.9 Test des odeurs : Signification implicite
11.10 Ajout de nouveaux tests
11.11 En conclusion
Partie 4 : Une image plus grande du test unitaire
Chapitre 12 Développement piloté par les tests
12.1 Les principaux avantages du TDD
12.2 Commencer simplement
12.3 Ajouter un autre incrément
12.4 Résumé du test
12,5 Une autre petite augmentation
12.6 Prise en charge des réponses multiples : un contournement mineur de conception
12.7 Extensions d'interface
12.8 Tests finaux
12.9 Les tests comme documentation
12.10 Le rythme du TDD
12.11 En conclusion
Chapitre 13 : Des épreuves difficiles
13.1 Tests de code multithread
13.1.1 Faites simple et intelligent
__13.1.2 Trouver toutes les correspondances
__13.1.3 Extraction de la logique applicative
__13.1.4 Repensé pour prendre en charge les tests de la logique des threads
__13.1.5 Écriture de tests pour la logique des threads
13.2 Tests de base de données
__13.2.1 Merci, Contrôleur
__13.2.2 Problèmes liés aux données
__13.2.3 Tests de base de données en salle blanche
__13.2.4 Traitement simulé du contrôleur
13.3 En conclusion
Tests du projet du chapitre 14
14.1 Introduction rapide
14.2 Soyez du même côté que l'équipe
14.2.1 Création d'une norme de test unitaire
14.2.2 Amélioration de la conformité aux normes grâce aux évaluations
__14.2.3 Révision par la programmation en binôme
14.3 Convergence par intégration continue
14.4 Couverture du code
__14.4.1 Quelle devrait être la couverture ?
__14.4.2 Une couverture à 100 % est-elle vraiment si bonne ?
__14.4.3 La valeur de la couverture de code
14.5 En conclusion
Annexe A : Configuration de JUnit dans IntelliJ IDEA et NetBeans
A.1 IntelliJ IDEA
A.2 NetBeans
Chapitre 1 : Créer votre premier test JUnit
1.1 Pourquoi écrire des tests unitaires ?
1.2 Notions de base de JUnit : Réussir son premier test
__1.2.1 Paramètres du projet
1.2.2 Comprendre un peu mieux les tests JUnit
__1.2.3 Exécution de JUnit
1.3 Préparation, exécution et validation des tests
1.4 Les tests testent-ils vraiment quelque chose ?
1.5 En conclusion
Chapitre 2 : Utiliser JUnit en conditions réelles
2.1 Compréhension du sujet testé : Classe de profil
2.2 Déterminez les tests que vous pouvez rédiger
2.3 Couverture à chemin unique
2.4 Création d'un deuxième test
2.5 Initialisation des tests avec la méthode @Before
2.6 Et maintenant ?
2.7 En conclusion
Chapitre 3 : Approfondissement des assertions JUnit
3.1 Assertions JUnit
__3.1.1 assertTrue
__3.1.2 assertThat compare une valeur spécifique
3.1.3 Examen de l'important comparateur Hamcrest
3.1.4 Comparaison de deux nombres à virgule flottante
__3.1.5 Explication de l'assertion
3.2 Trois façons d'anticiper les exceptions
3.2.1 La méthode simple : utiliser des annotations
3.2.2 L'ancienne méthode : try/catch et échec
3.2.3 Nouvelle méthode : règle ExpectedException
3.2.4 Ignorer les exceptions
3.3 En conclusion
Chapitre 4 Organisation du test
4.1 Maintien de la cohérence des tests avec AAA
4.2 Tests comportementaux vs. tests de méthode
4.3 Relation entre les tests et le code de production
4.3.1 Séparation du code de test et du code de production
4.3.2 Exposition aux données internes vs. exposition aux comportements internes
4.4 La valeur des tests ciblés à objectif unique
4.5 Les tests comme documentation
4.5.1 Documenter les tests avec des noms cohérents
4.5.2 Donner du sens aux tests
4.6 En savoir plus sur @Before et @After (initialisation et nettoyage communs)
4.6.1 Annotations BeforeClass et AfterClass
4.7 Le vert, c'est bien : garder les tests pertinents
4.7.1 Tests plus rapides
__4.7.2 Tests exclus
4.8 En conclusion
Partie 2 : Acquisition de techniques de mémorisation rapide
Chapitre 5 : Les PREMIERS attributs d’un bon test
5.1 PREMIÈRE ÉTAPE : Bonnes conditions de test
5.2 [F]PREMIER : Rapide
5.3 PREMIÈRE ÉTAPE : Isoler
5.4 PREMIER : Les bons tests doivent être reproductibles.
5.5 PREMIER : Auto-vérifiable
5.6 FIRS[T] : À utiliser au bon moment
5.7 En conclusion
Chapitre 6 - BICEPS droit : Que tester ?
6.1 [Droit]-BICEP : Les résultats sont-ils corrects ?
6.2 Droite-[B]ICEP : Les conditions aux limites sont-elles correctes ?
6.3 N'oubliez pas que les conditions aux limites sont CORRECTES
6.4 Right-B[I]CEP : Peut-on tester la relation inverse ?
6.5 Right-BI[C]EP : La vérification croisée peut-elle être effectuée par d'autres moyens ?
6.6 Right-BIC[E]P : Peut-on forcer une condition d'erreur à se produire ?
6.7 Right-BICE[P] : Les conditions de performance répondent-elles aux normes ?
6.8 En conclusion
Chapitre 7 Conditions aux limites : Mnémonique CORRECTE
7.1 [C]ORRECT : [C]onformité
7.2 CORRECT : Commande
7.3 CO[R]RECT : [R]ange(range)
__7.3.1 Création d'un comparateur personnalisé qui vérifie l'invariance
7.3.2 Tests de plage en intégrant des méthodes immuables
7.4 CORRECT : Référence
7.5 CORR[E]CT : [E]n existence
7.6 CORRE[C]T : [C]ardinité
7.7 CORREC[T]: [T]ime(temps)
7.8 En conclusion
Partie 3 : La vision d'ensemble du projet
Chapitre 8 : Refactorisation vers un code propre
8.1 Refactorisation mineure
8.1.1 Opportunités de refactorisation
8.1.2 Méthodes d'extraction : votre deuxième allié le plus précieux en matière de refactorisation
8.2 Trouver un meilleur foyer pour les méthodes
8.3 Refactorisation automatique et manuelle
8.4 Refactorisation excessive ?
8.4.1 Récompenses : Unités claires et testables
8.4.2 Problèmes de performance : Ne soyez pas
8.5 En conclusion
Chapitre 9 : Problèmes de conception plus importants
9.1 Classes de profils et SRP
9.2 Extraction d'une nouvelle classe
9.3 Séparation des commandes et des requêtes
9.4 Coûts de maintenance des tests unitaires
__9.4.1 Comment se protéger
__9.4.2 Correction des tests défectueux
9.5 Réflexions sur d'autres modèles
9.6 En conclusion
Chapitre 10 Utilisation de l'objet Cou
10.1 Défis des tests
10.2 Remplacement des actions complexes par des ébauches
10.3 Modifications de conception pour faciliter les tests
10.4 Ajouter de l'intelligence aux ébauches : validation des arguments
10.5 Simplifier les tests à l'aide de l'outil de simulation
10.6 Une dernière simplification : présentation de l’outil d’injection
10.7 Ce qui est important pour bien utiliser son cou
10.8 En conclusion
Chapitre 11 : Refactorisation des tests
11.1 Comprendre la recherche
11.2 Tests suspects : Code de test inutile
11.3 Défauts de test : Absence d’abstraction
11.4 Test olfactif : Informations inappropriées
11.5 Test olfactif : Puffy Creation
11.6 Test olfactif : Affirmations multiples
11.7 Tests olfactifs : détails non pertinents pour les tests
11.8 Test d'odeur : Mauvaise organisation
11.9 Test des odeurs : Signification implicite
11.10 Ajout de nouveaux tests
11.11 En conclusion
Partie 4 : Une image plus grande du test unitaire
Chapitre 12 Développement piloté par les tests
12.1 Les principaux avantages du TDD
12.2 Commencer simplement
12.3 Ajouter un autre incrément
12.4 Résumé du test
12,5 Une autre petite augmentation
12.6 Prise en charge des réponses multiples : un contournement mineur de conception
12.7 Extensions d'interface
12.8 Tests finaux
12.9 Les tests comme documentation
12.10 Le rythme du TDD
12.11 En conclusion
Chapitre 13 : Des épreuves difficiles
13.1 Tests de code multithread
13.1.1 Faites simple et intelligent
__13.1.2 Trouver toutes les correspondances
__13.1.3 Extraction de la logique applicative
__13.1.4 Repensé pour prendre en charge les tests de la logique des threads
__13.1.5 Écriture de tests pour la logique des threads
13.2 Tests de base de données
__13.2.1 Merci, Contrôleur
__13.2.2 Problèmes liés aux données
__13.2.3 Tests de base de données en salle blanche
__13.2.4 Traitement simulé du contrôleur
13.3 En conclusion
Tests du projet du chapitre 14
14.1 Introduction rapide
14.2 Soyez du même côté que l'équipe
14.2.1 Création d'une norme de test unitaire
14.2.2 Amélioration de la conformité aux normes grâce aux évaluations
__14.2.3 Révision par la programmation en binôme
14.3 Convergence par intégration continue
14.4 Couverture du code
__14.4.1 Quelle devrait être la couverture ?
__14.4.2 Une couverture à 100 % est-elle vraiment si bonne ?
__14.4.3 La valeur de la couverture de code
14.5 En conclusion
Annexe A : Configuration de JUnit dans IntelliJ IDEA et NetBeans
A.1 IntelliJ IDEA
A.2 NetBeans
Image détaillée
.jpg)
Dans le livre
Peu de temps après avoir écrit les premières éditions de The Pragmatic Programmer et Programming Ruby, Dave Thomas et moi (Andy Hunt) avons porté notre attention sur les besoins les plus fondamentaux du développeur de logiciels moderne.
Cette réflexion a donné naissance à « Starting Tools for Pragmatic Programmers ».
Ces trois ouvrages couvrent les éléments fondamentaux dont une équipe a besoin, à savoir le contrôle de version, les tests unitaires, ainsi que les compilations et les tests automatisés.
Ces livres constituent la première série que nous avons publiée après la création de « The Pragmatic Bookshelf ».
Jeff Langer a travaillé à adapter et à développer notre livre pour le monde moderne.
Les principes restent les mêmes, mais les outils sont bien meilleurs, et l'approche globale du développement logiciel est beaucoup plus pratique, professionnelle et (si je puis dire) plus pragmatique.
Dans ce livre, Jeff vous montrera ce chemin.
Les tests n'ont pas toujours été considérés comme importants dans les activités de programmation.
Ce nom était bien loin du codage, du design et du débogage.
Mais la vérité est différente.
Le compilateur/interpréteur d'un langage de programmation vérifie que le code source est grammaticalement valide.
Au moins, assurez-vous qu'elle ait une forme cohérente selon la grammaire de la langue.
Mais le compilateur ne vous dit pas ce que fait ce code, et il ne peut rien déterminer quant à sa validité.
Dans ce cas précis, les tests unitaires spécifient le comportement du code et vérifient ce comportement.
Les tests unitaires constituent un excellent point de convergence entre la conception, le codage et le débogage.
Si votre code de test ne vous apporte pas beaucoup de valeur, ce livre vous sera utile.
Cela vous sera également utile si vous débutez dans le domaine des tests unitaires ou si vous cherchez à tirer le meilleur parti de vos tests unitaires.
Andy Hunt
Cette réflexion a donné naissance à « Starting Tools for Pragmatic Programmers ».
Ces trois ouvrages couvrent les éléments fondamentaux dont une équipe a besoin, à savoir le contrôle de version, les tests unitaires, ainsi que les compilations et les tests automatisés.
Ces livres constituent la première série que nous avons publiée après la création de « The Pragmatic Bookshelf ».
Jeff Langer a travaillé à adapter et à développer notre livre pour le monde moderne.
Les principes restent les mêmes, mais les outils sont bien meilleurs, et l'approche globale du développement logiciel est beaucoup plus pratique, professionnelle et (si je puis dire) plus pragmatique.
Dans ce livre, Jeff vous montrera ce chemin.
Les tests n'ont pas toujours été considérés comme importants dans les activités de programmation.
Ce nom était bien loin du codage, du design et du débogage.
Mais la vérité est différente.
Le compilateur/interpréteur d'un langage de programmation vérifie que le code source est grammaticalement valide.
Au moins, assurez-vous qu'elle ait une forme cohérente selon la grammaire de la langue.
Mais le compilateur ne vous dit pas ce que fait ce code, et il ne peut rien déterminer quant à sa validité.
Dans ce cas précis, les tests unitaires spécifient le comportement du code et vérifient ce comportement.
Les tests unitaires constituent un excellent point de convergence entre la conception, le codage et le débogage.
Si votre code de test ne vous apporte pas beaucoup de valeur, ce livre vous sera utile.
Cela vous sera également utile si vous débutez dans le domaine des tests unitaires ou si vous cherchez à tirer le meilleur parti de vos tests unitaires.
Andy Hunt
--- Extrait de la « Préface »
Avis de l'éditeur
Le cœur du code propre,
Améliorez la qualité de vos logiciels grâce aux tests unitaires !
Les tests unitaires consistent à vérifier qu'un module de code spécifique fonctionne exactement comme prévu.
Cela vous permet d'identifier et de corriger rapidement tout problème survenant lors de la modification de votre code.
En d'autres termes, l'objectif des tests unitaires est de garantir la qualité du logiciel et d'améliorer la productivité.
Comment écrire des tests unitaires ? Ce livre explique les concepts fondamentaux des tests unitaires, depuis les raisons de leur écriture jusqu’aux bonnes pratiques de test, en passant par l’utilisation d’objets simulés, les tests unitaires automatisés et la refactorisation.
De plus, les tests unitaires sont structurés de manière à ce que vous puissiez vous entraîner étape par étape, et du code vérifié est inclus afin que vous puissiez apprendre comment le code fonctionne réellement.
- Principes fondamentaux des tests unitaires : Comprendre les concepts, configurer un environnement de test, votre premier test, les assertions JUnit
- Consignes de test : PREMIÈRE (conditions d’un bon test), BICEPS DROIT (ce qu’il faut tester), CORRECT (conditions limites)
- Vue d'ensemble de la conception : conception logicielle, refactoring, utilisation d'objets factices, tests de refactoring
- Vue d'ensemble des tests unitaires : développement piloté par les tests, tests de code multithread, tests de bases de données, tests unitaires en équipe
Améliorez la qualité de vos logiciels grâce aux tests unitaires !
Les tests unitaires consistent à vérifier qu'un module de code spécifique fonctionne exactement comme prévu.
Cela vous permet d'identifier et de corriger rapidement tout problème survenant lors de la modification de votre code.
En d'autres termes, l'objectif des tests unitaires est de garantir la qualité du logiciel et d'améliorer la productivité.
Comment écrire des tests unitaires ? Ce livre explique les concepts fondamentaux des tests unitaires, depuis les raisons de leur écriture jusqu’aux bonnes pratiques de test, en passant par l’utilisation d’objets simulés, les tests unitaires automatisés et la refactorisation.
De plus, les tests unitaires sont structurés de manière à ce que vous puissiez vous entraîner étape par étape, et du code vérifié est inclus afin que vous puissiez apprendre comment le code fonctionne réellement.
- Principes fondamentaux des tests unitaires : Comprendre les concepts, configurer un environnement de test, votre premier test, les assertions JUnit
- Consignes de test : PREMIÈRE (conditions d’un bon test), BICEPS DROIT (ce qu’il faut tester), CORRECT (conditions limites)
- Vue d'ensemble de la conception : conception logicielle, refactoring, utilisation d'objets factices, tests de refactoring
- Vue d'ensemble des tests unitaires : développement piloté par les tests, tests de code multithread, tests de bases de données, tests unitaires en équipe
SPÉCIFICATIONS DES PRODUITS
- Date de publication : 3 juillet 2019
Nombre de pages, poids, dimensions : 328 pages | 630 g | 152 × 225 × 30 mm
- ISBN13 : 9791160508383
- ISBN10 : 1160508380
Vous aimerez peut-être aussi
카테고리
Langue coréenne
Langue coréenne
![ELLE 엘르 스페셜 에디션 A형 : 12월 [2025]](http://librairie.coreenne.fr/cdn/shop/files/b8e27a3de6c9538896439686c6b0e8fb.jpg?v=1766436872&width=3840)
