#4 Journal d’un développeur chez Esker : relecture de code et tests
Cher journal,
Cela fait plus de deux ans que j’ai décroché mon premier emploi chez Esker. Je suis développeur dans une des dix équipes de la R&D en charge du développement des solutions à destination de nos clients. Nous sommes entre quatre et six développeuses/développeurs par équipe, et travaillons tous en méthode Agile sur une base de code commune afin de développer de nouvelles fonctionnalités pour nos produits. Mais notre travail ne se limite pas à ça ! Je tenterai donc de t’en présenter toutes les facettes en plusieurs articles. Tu peux retrouver les sujets précédents sur la page d’Esker Labs.
Ça y est, j’ai fini mon développement ! Mais si tu imagines que mon travail est terminé et que la fonctionnalité va directement aller en production, tu te trompes. Il faut aussi la tester.
Voilà une nouvelle facette de mon travail de développeur chez Esker que tu ne connais pas encore. Suite au développement d’une nouvelle story, la plupart des équipes organisent d’abord des relectures de code afin de vérifier qu’en théorie, le nouveau code réponde bien aux besoins identifiés initialement. Cette relecture permet parfois d’identifier en amont des problèmes que nous n’avions pas repérés (et donc de les corriger), mais il permet aussi de refactorer le code afin de le rendre plus lisible. Selon les équipes, plusieurs outils nous permettent de relire plus confortablement nos développements, les plus communément utilisés chez nous étant Phabricator et RhodeCode.
En effet, étant donné que la R&D est constituée d’équipes métier avec un socle commun, il est très probable que des développeuses/développeurs d’autres équipes soient amenés à repasser derrière nous pour améliorer le code, le retoucher, ajouter de nouvelles fonctionnalités… Dans ces cas-là, il sera bien plus facile pour eux de comprendre le code existant s’il a été rendu plus simple et lisible et s’il respecte les principes du clean code. Cette simple expression cache en réalité beaucoup de bonnes pratiques que nous essayons de respecter au maximum. Mais c’est un autre sujet que nous aborderons plus tard !
Suite à cette relecture, il est temps de tester en pratique la fonctionnalité développée. Les façons de tester sont diverses selon les équipes, et je n’essaierai donc pas de te les expliquer toutes, mais je peux néanmoins te parler de celle de mon équipe. Tout au long du sprint, nous construisons un plan de tests manuels, qui est en fait une liste de tout ce qu’il serait intéressant de vérifier suite au développement d’une story. Nous testons ensuite chaque point et vérifions aussi que les critères d’acceptance sont respectés. Ces critères sont créés par le Product Owner et représentent l’ensemble des conditions à respecter pour valider l’implémentation d’une nouvelle fonctionnalité.
Ces vérifications manuelles terminées, il serait en théorie possible de lancer la nouvelle fonctionnalité en production. Mais comment être sûr qu’elle ne sera pas impactée par un nouveau développement par la suite ? C’est là qu’interviennent les tests automatisés. Chez Esker, ils peuvent prendre plusieurs formes et peuvent être créés avant, pendant ou après le développement selon la story et l’équipe. Nous avons par exemple des tests unitaires, qui vérifient comme leur nom l’indique qu’une fonction seule fait bien ce qu’elle est censée faire et qui testent les cas limites. Ces tests unitaires sont écrits dans le même langage que le code à tester et utilisent parfois des frameworks de test spécifiques. Par exemple, pour ceux qui sont écrits en Javascript, nous utilisons QUnit.
D’autres tests nous permettent de vérifier qu’une fonctionnalité dans sa totalité se comporte comme nous le souhaitons. Les tests d’intégration ont pour objectif de tester un module (par exemple, les conversions). Les tests fonctionnels permettent, comme leur nom l’indique, de tester une fonctionnalité (par exemple, la possibilité pour un client d’approuver un document). Nous utilisons là encore plusieurs frameworks pour nous assister, l’un des plus utilisés par mon équipe étant Selenium, qui permet de piloter automatiquement des navigateurs. Tous ces tests sont lancés automatiquement chaque nuit grâce à Jenkins, un serveur d’automatisation permettant de builder, déployer ou automatiser un grand nombre de tâches. Lorsque ces tests tombent en erreur, cela signifie qu’un nouveau développement a entraîné une modification du comportement de notre solution, et il nous faut donc vérifier que les fonctionnalités testées sont toujours valides. Chaque équipe fait donc tourner ses tests toutes les nuits pour vérifier qu’aucune régression ne passera en production.
Concernant mon équipe, nous construisons souvent au fur et à mesure du développement de la story un test automatisé qui reprend les différents tests manuels que nous avons listés dans notre plan de test. Le test est ensuite rapidement intégré à notre ensemble de tests lancés chaque nuit. Chaque jour, nous regardons ceux qui sont en erreur et investiguons afin d’en déterminer la raison. Un peu comme Sherlock Holmes, mais pour le développement logiciel 😉
Tu as hâte de savoir la suite ? C’est par ici :
Retrouve les autres parties du journal d’un développeur chez Esker :
