Ressources
La qualité logicielle et les tests
Un test automatisé transforme une intention en garantie permanente. Il fixe le comportement attendu, il le vérifie à chaque modification, et il rend possible de reprendre un code écrit six mois plus tôt avec confiance.
Ce qu'un test rend possible
Écrire un test avant la correction transforme un symptôme en fait vérifiable : le test échoue, la cause est identifiée, la correction le fait passer, et la garantie reste acquise pour toujours. C'est ce qui permet à une équipe qui tourne de reprendre un code sans son auteur. La gestion de version conserve l'histoire de chaque décision, la revue de code fait circuler la connaissance, et l'intégration continue rejoue l'ensemble à chaque modification.
- Un test qui échoue d'abord : il prouve que la cause est bien celle-là
- Un test unitaire par règle de gestion, rapide et isolé
- Un test d'intégration par parcours utilisateur complet
- Une revue de code par modification, avant fusion
- Une intégration continue qui rejoue tout, à chaque envoi
Les quatre pratiques qui se renforcent
La gestion de version
Chaque modification porte son intention et son auteur. Retrouver pourquoi une ligne existe devient une question d'une minute.
La revue de code
Un second regard avant fusion. Elle diffuse les conventions bien plus efficacement qu'un document de règles.
Les patrons de conception
Des solutions nommées à des problèmes récurrents. Le nom partagé raccourcit la discussion d'architecture.
L'architecture en couches
La logique métier séparée de l'infrastructure. Changer de base de données cesse alors d'être un projet entier.
Le cursus qui porte ces pratiques
Le génie logiciel et la mise en production occupent des blocs entiers, avec leur volume horaire propre. Le tableau donne le poids réel de chaque enseignement dans le cursus.
| Bloc d'enseignement | Année | Heures | Crédits |
|---|---|---|---|
| Socle du web | 1 | 200 h | 20 |
| JavaScript et TypeScript | 1 | 220 h | 22 |
| Interfaces de programmation et données | 1 | 160 h | 16 |
| Applications React et développement mobile | 2 | 240 h | 24 |
| Mise en production | 2 | 140 h | 14 |
| Socle transversal | 1-2 | 120 h | 12 |
| Projet et stage | 2 | 120 h | 12 |
Questions sur les tests
Combien de tests écrire ?
Autant qu'il y a de règles de gestion, et un par parcours utilisateur complet. La bonne mesure est celle-ci : après une modification, la suite de tests suffit à décider si le logiciel part en production.
Les tests ralentissent-ils le développement ?
Ils déplacent le temps : quelques minutes à l'écriture, contre des heures de diagnostic évitées à chaque reprise. Sur un logiciel maintenu plus de trois mois, l'écart se lit très vite en faveur des tests.
Quelle place la revue de code occupe-t-elle dans l'évaluation ?
Elle est une compétence évaluée à part entière : vous relisez le travail d'un pair avec la grille officielle, et la qualité de votre relecture compte dans la validation du bloc. Corriger apprend autant que produire.
À explorer ensuite
- Le site web d'une PMECréer le site d'une petite entreprise : objectif, arborescence, rédaction, mise en ligne, nom de domaine, certificat, référencement et mesure d'audience.
- Applications mobilesDéveloppement mobile multiplateforme : base de code unique, fonctionnement hors ligne, synchronisation, publication sur les magasins et suivi des versions.
- Concevoir une interfaceEnquête utilisateur, architecture de l'information, hiérarchie visuelle, états d'un composant et test d'utilisabilité : la méthode de conception d'interface.
- Accessibilité numériqueContraste, navigation au clavier, lecteur d'écran, connexion faible : les vérifications d'accessibilité et la façon de les intégrer au travail courant.
- Système de composantsJetons de conception, bibliothèque de composants, documentation et passage à l'intégration : construire un système d'interface qui tient à l'échelle.
- Écrire pour le webTechniques de rédaction web : information en tête, titres qui répondent, phrases courtes, mots que les lecteurs emploient, appels à l'action clairs.