Fred
/
gwift-book
1
0
Fork 1
Code Issues 64 Pull Requests 3 Releases 11 Wiki Activity

Reecriture

This commit is contained in:
Gregory Trullemans 2023-04-21 14:13:08 +02:00
parent 6fa6fa3f7d
commit 7c4682e29b
1 changed files with 24 additions and 30 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

54
chapters/tests.tex
View File

@ -1,4 +1,3 @@
\chapter{Tests unitaires et d'intégration}
\begin{quote}
@ -16,10 +15,8 @@ Tests are as important as the implementation itself (all that matters is that th
Unit tests combine many features that make them your secret weapon to application success:
\begin{enumerate}
\item
Design aid: Writing tests first gives you a clearer perspective on the ideal API design.
\item
Feature documentation (for developers): Test descriptions enshrine in code every implemented feature requirement.
\item Design aid: Writing tests first gives you a clearer perspective on the ideal API design.
\item Feature documentation (for developers): Test descriptions enshrine in code every implemented feature requirement.
\item
Test your developer understanding: Does the developer understand the problem enough to articulate in code all critical component requirements?
\item
@ -34,19 +31,18 @@ Rather, it is in the essential nature of a unit test to satisfy all of those nee
These benefits are all side-effects of a well-written test suite with good coverage.
\begin{enumerate}
\item
What component aspect are you testing?
\item
What should the feature do? What specific behavior requirement are you testing?
\item What component aspect are you testing?
\item What should the feature do? What specific behavior requirement are you testing?
\end{enumerate}
Traduit grossièrement depuis un article sur \url{https://medium.com/javascript-scene/what-every-unit-test-needs-f6cd34d9836d\#.kfyvxyb21\%3E\%60_}:
Traduit grossièrement depuis un article sur \url{https://medium.com/javascript-scene/what-every-unit-test-needs-f6cd34d9836d\#.kfyvxyb21\%3E\%60_} :
% TODO : Finir le verbatim ci-dessous : "ils sont.... ??????"
% TODO : Finir le verbatim ci-dessous : "ils sont\ldots. ??????"
\begin{verbatim}
Vos tests sont la première et la meilleure ligne de défense contre les défauts de programmation. Ils sont
\end{verbatim}
% TODO : Pourquoi il finit par ":" le verbatim ci-dessous ?
\begin{verbatim}
Les tests unitaires combinent de nombreuses fonctionnalités, qui en fait une arme secrète au service d'un développement réussi:
\end{verbatim}
@ -54,12 +50,9 @@ Traduit grossièrement depuis un article sur \url{https://medium.com/javascript-
\begin{enumerate}
\item
Aide au design: écrire des tests avant d'écrire le code vous donnera une meilleure perspective sur le design à appliquer aux API.
\item
Documentation (pour les développeurs): chaque description d'un test
\item
Tester votre compréhension en tant que développeur:
\item
Assurance qualité: des tests, 5.
\item Documentation (pour les développeurs): chaque description d'un test
\item Tester votre compréhension en tant que développeur:
\item Assurance qualité: des tests, 5.
\end{enumerate}
@ -103,9 +96,11 @@ Cette complexité est liée à deux concepts:
\begin{itemize}
\item
\textbf{La lisibilité du code}: au plus la complexité cyclomatique sera élevée, au plus le code sera compliqué à comprendre en première instance. Il sera composé de plusieurs conditions, éventuellement imbriquées, il débordera probablement de la hauteur que votre écran sera capable d'afficher
\textbf{La lisibilité du code} : au plus la complexité cyclomatique sera élevée, au plus le code sera compliqué à comprendre en première instance.
Il sera composé de plusieurs conditions, éventuellement imbriquées, il débordera probablement de la hauteur que votre écran sera capable d'afficher.
\item
\textbf{Les tests unitaires}: pour nous assurer d'une couverture de code correcte, il sera nécessaire de couvrir tous les embranchements présentés. Connaître la complexité permet de savoir combien de tests devront être écrits pour assurer une couverture complète de tous les cas pouvant se présenter.
\textbf{Les tests unitaires} : pour nous assurer d'une couverture de code correcte, il sera nécessaire de couvrir tous les embranchements présentés.
Connaître la complexité permet de savoir combien de tests devront être écrits pour assurer une couverture complète de tous les cas pouvant se présenter.
\end{itemize}
@ -175,8 +170,9 @@ indépendamment des autres. \cite{clean_code}
Le plus important est de toujours corréler les phases de tests indépendantes du reste du travail (de développement, ici), en l’automatisant au plus près de sa source de création:
\begin{quote}
Martin Fowler observes that, in general, "a ten minute build [and test process] is perfectly within reason...
[We first] do the compilation and run tests that are more localized unit tests with the database completely stubbed out. Such tests can run very fast, keeping within the ten minutes guideline.
Martin Fowler observes that, in general, "a ten minute build [and test process] is perfectly within reason\ldots
[We first] do the compilation and run tests that are more localized unit tests with the database completely stubbed out.
Such tests can run very fast, keeping within the ten minutes guideline.
However any bugs that involve larger scale intercations, particularly those involving the real database, won’t be found.
The second stage build runs a different suite of tests [acceptance tests] that do hit the real database and involve more end-to-end behavior.
This suite may take a couple of hours to run.
@ -192,7 +188,7 @@ Le plus important est de toujours corréler les phases de tests indépendantes d
\end{quote}
Les tests unitaires ciblent typiquement une seule fonction, classe ou méthode, de manière isolée, en fournissant au développeur l’assurance que son code réalise ce qu’il en attend.
Pour plusieurs raisons (et notamment en raison de performances), les tests unitaires utilisent souvent des données stubbées - pour éviter d’appeler le "vrai" service
Pour plusieurs raisons (et notamment en raison de performances), les tests unitaires utilisent souvent des données stubbées - pour éviter d’appeler le "vrai" service.
Le nombre de tests unitaires nécessaires à la couverture d'un bloc fonctionnel est au minimum égal à la complexité cyclomatique de ce bloc.
Une possibilité pour améliorer la maintenance du code est de faire baisser ce nombre, et de le conserver sous un certain seuil.
@ -200,26 +196,24 @@ Certains recommandent de le garder sous une complexité de 10; d'autres de 5.
Idéalement, chaque fonction ou méthode doit être testée afin de bien en valider le fonctionnement, indépendamment du reste des composants.
Cela permet d'isoler chaque bloc de manière unitaire, et permet de ne pas rencontrer de régression lors de l'ajout d'une nouvelle fonctionnalité ou de la modification d'une existante.
Il existe plusieurs types de tests (intégration, comportement, ...)
Il existe plusieurs types de tests (intégration, comportement, \ldots)
Avoir des tests, c'est bien.
S'assurer que tout est testé, c'est mieux.
C'est ici qu'il est utile d'avoir le pourcentage de code couvert par les différents tests, pour savoir ce qui peut être amélioré, le but du jeu consistant simplement à augmenter ou égaler le pourcentage de couverture de code existant avant chaque modification.
Gitlab permet de visualiser cette information de manière très propre, en l'affichant au niveau de chaque proposition d'intégration.
La couverture de code est une analyse qui donne un pourcentage lié à la quantité de code couvert par les tests. Attention qu'il ne s'agit pas de vérifier que le code est \textbf{bien} testé, mais juste de vérifier \textbf{quelle partie} du code est testée.
La couverture de code est une analyse qui donne un pourcentage lié à la quantité de code couvert par les tests.
Attention qu'il ne s'agit pas de vérifier que le code est \textbf{bien} testé, mais juste de vérifier \textbf{quelle partie} du code est testée.
Le paquet \texttt{coverage} se charge d'évaluer le pourcentage de code couvert par les tests.
\subsection{Tests d'acceptance}
\begin{quote}
The objective of acceptance tests is to prove that our application does
what the customer meant it to.
The objective of acceptance tests is to prove that our application does what the customer meant it to.
\end{quote}
Les tests d’acceptance vérifient que l’application fonctionne comme convenu, mais à un plus haut niveau (fonctionnement correct d’une API, validation d’une chaîne d’actions effectuées par un humain, ...).
Les tests d’acceptance vérifient que l’application fonctionne comme convenu, mais à un plus haut niveau (fonctionnement correct d’une API, validation d’une chaîne d’actions effectuées par un humain, \ldots).
\subsection{Tests d'intégration}
Les tests d’intégration vérifient que l’application coopère correctement avec les systèmes
périphériques
Les tests d’intégration vérifient que l’application coopère correctement avec les systèmes périphériques.