Addict aux tests unitaires ? Voici une idée pour y remédier | de Mike Cronin | janvier 2023

Asseyez-vous internet, c’est une intervention

Dans le développement Web moderne, quelque chose que j’ai remarqué, c’est que nous avons tendance à faire le plus de tests là où c’est le plus simplemais pas nécessairement là où c’est le plus avait besoin. Je ne dis absolument pas qu’écrire du code testable est mauvais, mais le fait est que tout le code n’est pas facilement testable. Il n’y a pas d’application Web sérieuse sur cette terre qui ne parle pas aux bases de données et aux services externes, n’envoie pas ses journaux ou quelque chose ça complique les choses. Et si nous renonçons à tester ces pièces au profit de sur-tester les périphériques, nous aurons des problèmes.

C’était tout pour moi. La paille a non seulement brisé le dos de mon chameau, mais l’a frappé au visage pour faire bonne mesure. Voir:

const convertTimestamp = (timestamp) => {
try{
return timestamp.toIsoString()
catch (e) {
logger.error(`We goofed: ${e.toString()}`);
return '';
}
}
const formatMessageObj = (rawMessage) => {
const { 
id,
name, 
created_at: created,
session_start_time: sessionStart, 
timestamp,
session_users: users,
} = rawMessage;
return {
id,
created,
sessionStart,
users,
timestampISO:  convertTimestamp(timestamp),
}
}

Quelques petites aides pratiques, rien de mal là-bas. C’est quoi, 25 lignes ? Pas beaucoup de logique autre que l’horodatage si nous sommes honnêtes. Je veux que vous deviniez combien de lignes de code cela avait dans les tests.

176 lignes.

Vous plaisantez j’espère? Il a fallu près de 200 lignes pour vérifier si nous… avons renommé des propriétés ? L’un des tests a vérifié si ce code pouvait gérer à la fois plein et vide session_users tableaux. Quoi? Il n’y a aucune logique ! C’est juste copier une propriété exactement. Si session_users était une chaîne d’adresse vers un NFT, ce code le copierait toujours.

Le botteur

J’ai encore cassé le code. J’ai gros doigts un extra } dans le modèle de chaîne lors de la modification du message d’erreur et foiré l’impression. Ce message d’erreur, en 176 lignes de tests, n’a jamais été réellement vérifié. Cette fonction est de 6 lignes, et nous avons quand même réussi à en manquer une. 176 lignes de tests.

Catapulte mon corps dans le putain Soleil.

Je ne peux pas crois que je dis cela, mais dans certains cas, je préférerais du code non testé que des tests unitaires redondants. Oof, comme je l’ai dit, une petite partie de mon âme vient de se briser. Mais c’est vrai. Et je vais vous dire pourquoi : un faux sentiment de sécurité peut être dangereux. Encore une fois, pour cette section du code, il y avait environ 200 lignes de test pour environ 300 lignes de code. Cela semble peut-être un peu léger, mais pas atroce. Ou alors j’ai pensé.

J’étais un imbécile, un Muppet absolu d’un homme. Si j’avais lu de plus près, j’aurais vu les mensonges. Sur les 300 lignes de code réel, il y a 21 fonctions au total. Nous n’en testions que 4. 4 ! Je viens d’en énumérer 2, les autres sont également des fonctions d’assistance pures. Sachez que ce service dispose d’une connexion à une base de données interne, d’une intégration DataDog, d’un service de base de données externe et s’appuie sur une bibliothèque partagée. Ne serait-ce pas de bonnes choses à vérifier? Cet incident est la raison pour laquelle les rapports de couverture de code générés automatiquement sont un outil si essentiel.

Il n’y a rien de mal à avoir des tests unitaires, il y a est quelque chose ne va pas avec seul avoir des tests unitaires, surtout les mauvais. Les simulations et les tests d’intégration plus intenses sont plus difficiles à écrire et à entretenir (en particulier les simulations), mais si bien fait ils en valent toujours la peine.

Les bogues aiment se glisser dans les points de connexion de notre code, il est donc crucial de faire autant de tests dans le monde réel que possible pour une confiance élevée. Écoute, je comprends pourquoi on lésine sur les tests. Nous tous savoir les tests sont bons, mais nous sommes surchargés de travail et dans les délais. Mais, le temps pour qu’un cadre de test approprié soit ajouté au code est comme il est écrit. Mais, lorsque des projets sont lancés, il y a des excuses assez familières :

« Cela prendra trop de temps pour gérer les tests d’intégration »
« Nous testerons après avoir fait fonctionner ce MVP »
« Obtenez simplement le chemin heureux »
« Cypress est cool, nous devrions le faire un jour. Pas aujourd’hui, évidemment, mais un jour »

Maintenant, je sais que ce n’est pas toutes les entreprises, et ce n’est même pas tous les projets. Les priorités changent et les besoins des entreprises l’emportent sur les meilleures pratiques. Si cet article vous touche un peu trop, alors je pense qu’il est temps de poser notre pied. Personnellement, j’ai vu notre base de code grandir dans des délais stricts, et j’ai malheureusement vu que les tests ne parvenaient pas à suivre.

Honnêtement, tout se résume à une idée simple : se battre pour le temps il faut écrire des tests qui vous mettent en confiance. Quelconque Nouveau fonctionnalité doit être entièrement testée. En faisant cela, vous ajouterez probablement de meilleurs tests, et probablement aussi des utilitaires de test. Vous pourrez ajouter des modèles de test plus succincts et copiables. Et puis, après quelques fonctionnalités totalement couvertes, vous aurez une suite de nouveaux outils et techniques à utiliser. Maintenant, avec votre nouvel arsenal de connaissances et d’utilitaires, revenir en arrière et ajouter/refactoriser les anciens tests devrait être beaucoup plus facile.

Comment vous allez faire les nouveaux tests n’a pas d’importance. Utilisez le framework et les techniques que vous souhaitez (vous pouvez même utiliser le TDD complet, cependant Je suis sceptique sur la plupart des implémentations là). Privilégiez la qualité à la quantité avec les nouveaux tests. Si vous êtes sous les délais, la pression va sucer. Mais de bons tests vous accélèrent finalement à long terme. Une suite de tests fiable vous donne la confiance nécessaire pour ajouter et refactoriser des fonctionnalités.

Les tests unitaires sont un outil incroyable, facilement l’épine dorsale de toute bonne suite de tests. Mais ils ne peuvent pas le faire seuls. Prenez le temps d’ajouter des tests plus intégrés et approfondis, et vous serez 1000% mieux lotis.

bon codage à tous,

Mike