Être un software crafter ne veut pas dire maîtriser toutes les technologies et méthodologies. C’est avant tout un mindset: celui de toujours chercher à produire de la valeur sans renier la qualité, de mettre l’amélioration continue au premier plan.

Je me considère aspirant software crafter, et aujourd’hui j’aimerais partager avec vous un morceau du chemin que j’ai parcouru: l’écriture de tests.

L’écriture de tests: un sujet délicat

A ce stade de la lecture, les plus expérimentés d’entre vous commencent probablement à vous offusquer que ce sujet n’ait rien de délicat: Il faut faire des tests, un point c’est tout !

Pourtant, est-ce la réalité? Vous conviendrez que rares sont les cadres où le testing est justement valorisé.

Vous êtes certainement passés par des entreprises où cette pratique était considérée comme un centre de coûts. Ou plus généralement, une obligation provoquée par un gate keeping forçant un pourcentage de couverture, sans grande conviction.

Cette réalité se matérialise également dans les projets personnels: écrivez-vous systématiquement des tests dans ce cas de figure?

Pour ma part, je vais peut-être vous décevoir, mais la réponse est non.

Et c’est précisément ce dont je vais vous parler.

Un projet perso, ce doit avant tout être fun !

En tant que développeurs, nous consacrons la plupart de notre temps de travail à des activités de développement. Selon le côté de la frontière duquel vous vous situez, on parle donc de 35 à 42 h par semaine.

Après avoir passé tant de temps dans le code, qu’est-ce qui peut motiver quelqu’un à investir de son temps personnel pour remettre les mains dedans ?

Il y a bien des raisons possibles, à tel point que ce sujet mériterait un article à part entière. Pour la jouer courte, dans mon cas, il s’agit de répondre à un besoin, et avoir du fun.

Pour moi, un projet personnel n’est viable que s’il répond à une problématique qui me touche au quotidien. C’est à cette seule condition que je le concrétiserais, car sa réalisation m’apporterait un gain concret dans ma vie de tous les jours: il répond à un besoin, il apporte de la valeur.

Après avoir élucidé l’objectif d’un projet personnel, il reste un point tout aussi important: quelles technologies et méthodologies utiliser pour le réaliser ?

Ces élans de motivation qui mènent à réaliser des développements sur le temps libre, c’est justement l’occasion d’expérimenter. Il serait dommage de se restreindre aux technologies utilisées dans notre quotidien.

Au final, un projet perso, ce doit avant tout être fun ! Sortir des sentiers battus, expérimenter de nouvelles choses, tester de nouvelles technologies pour voir à quel point elles sont agréables à utiliser…

Sauf que voilà: parfois, cette recherche du fun obscurcit notre vision, et mène à de mauvaises décisions

L’histoire d’un projet qui démarrait bien…

Ces derniers mois, je me suis grandement intéressé à Svelte. Il s’agit d’un framework Javascript, au même titre que Angular ou React. Ce qui m’a mené à explorer Svelte est sa facilité d’utilisation, liée à une syntaxe nécessitant bien moins de boilerplate que ce qui se fait avec d’autres frameworks. Les performances à l’exécution sont également très bonnes, la boucle de feedback s’en voit très accélérée: un plaisir à utiliser !

Malheureusement, tout n’est pas rose : Svelte se veut actuellement agnostique en termes d’outils de test. Ce qui implique que lorsque l’on crée un projet, il ne vient pas avec une configuration de test prête à l’emploi (à l’instar d’autres frameworks, tels que ceux cités précédemment).

Après avoir consacré du temps à tenter de pallier ce problème sans succès, j’ai pris la décision de partir dans la réalisation de mon projet malgré tout. A ce stade, on fait donc une croix sur toute possibilité d’écriture de tests, la configuration nécessaire étant absente.

J’ai réalisé ce projet sur quelques mois, en y consacrant quelques heures par-ci par-là. Dans les faits, je pourrais découper ces développements en 3 phases:

• Le démarrage du projet: mise en place de la stack technique et réalisation du MVP en ayant un focus sur les fonctionnalités à forte valeur et faible coût. Tout roule, j’avance de manière fluide.
• L’ajout de fonctionnalités: étant sur une bonne lancée, je commence à aller plus loin, le périmètre du projet grossit, le nombre de fonctionnalités augmente. Ça roule toujours, mais je commence à payer l’absence de tests: je consacre une attention particulière à tester manuellement les différentes fonctionnalités, ce qui me ralentit.
• Le polissage: satisfait du résultat, je souhaite donner un côté sympa à mon projet, en y ajoutant des éléments un peu plus chers, mais améliorant l’expérience utilisateur. Je me fais alors rattraper par mes décisions précédentes: je parviens tant bien que mal à boucler le sujet, après avoir essuyé quelques plâtres liés à des effets de bord.

J’arrive alors dans la phase que tout développeur redoute: celle où l’on ne fait plus confiance au code. Le fun de la techno et du sujet commence à s’effacer au détriment de la crainte d’avoir des effets de bord. L’investissement de temps/énergie nécessaire pour remettre le projet à plat devient un facteur de dissuasion très puissant.

C’est souvent à ce moment que les jours d’un projet perso commencent à être comptés: l’effort nécessaire augmente, la motivation baisse, et le temps accordé finit par disparaître.

Un projet au point mort

A ce niveau de progression, je suis désormais convaincu que ce projet a besoin de tests. Pourtant, la configuration permettant d’en exécuter étant absente, je me vois contraint de rattraper ce retard alors que le projet est bien avancé.

Malgré les heures investies sur ce sujet, je ne suis pas parvenu à un résultat positif : la spécificité de mon projet (Svelte + SvelteKit + TypeScript) fait qu’il n’est pas aisé aujourd’hui d’obtenir une configuration correcte.

J’en viens donc à devoir rembourser une dette que je ne suis pas en mesure de payer aujourd’hui. Aïe.

Ma stratégie actuelle est de sonder les tickets GitHub des projets concernés, notamment SvelteKit, afin de suivre les avancées réalisées concernant le testing. Mon projet est donc au point mort, en attendant d’avoir une option viable à exploiter.

Cet arrêt “forcé” est brutal, mais il me permet de prendre du recul.. recul qui prend notamment la forme de cet article.

À date d’aujourd’hui, je ne suis pas sûr d’utiliser Svelte sur un autre projet. Ne vous méprenez pas : Svelte est un excellent atout à avoir en main, son potentiel est incroyable !

Par contre, partir sur une techno qui ne permet pas facilement d’écrire des tests devrait être un NO-GO.

Bonus

Lors de mes recherches concernant le niveau de maturité de Svelte en termes de testing, j’ai observé quelque chose d’intriguant: Rich Harris, créateur de Svelte, a exprimé le fait qu’il ne toucherait pas Jest, même avec un bâton.

Pourtant, Jest représente aujourd’hui la solution la plus populaire en termes d’écriture de tests unitaires dans un écosystème Javascript.

Pour ma part, il s’agit de mon outil de prédilection, aussi j’ai été grandement étonné de voir un positionnement aussi tranché sur le sujet.

Si l’équipe contribuant à Svelte ne paraît pas avoir un outil unique pour tester, il semble y avoir un consensus pour dire que uvu est plus efficace que Jest.

J’ignore ce qu’il en est de votre côté, mais cet outil m’était totalement étranger. Les arguments sont intéressants, aussi je vais tester uvu prochainement, pour voir ce qu’il en ressort.

Qu’y a-t-il à retenir ?

• Ne pas tester sur un projet One-Shot, c’est faisable.
• Ne pas tester sur un projet que l’on souhaite faire vivre, c’est une très mauvaise idée.
• Quand on choisit une technologie, il faudrait systématiquement considérer la facilité à tester en premier lieu.

Un projet sans tests, c’est comme une voiture sans volant: ça peut avoir de l’allure et aller vite, mais ça finira forcément dans un mur.