Twitter rend open source son outil Diffy qui permet de détecter automatiquement des bugs dans les codes

Twitter rend open source son outil Diffy
Qui permet aux développeurs de détecter automatiquement des bugs potentiels dans leurs codes

Après l’avoir utilisé en production pour ses propres besoins en interne, Twitter rend open source son outil Diffy. Ce morceau de programme permet aux développeurs de repérer automatiquement - donc plus facilement et plus vite – des bugs potentiels dans leur code après y avoir apporté des mises à jour. Si Diffy nécessite une configuration minimale, il évite toutefois aux développeurs d’écrire de nombreux tests, comme l’explique l’entreprise de réseautage social.

La technique utilisée par Diffy pour détecter des bugs potentiels dans un service est d’exécuter côte à côte plusieurs instances du nouveau et de l’ancien code et ensuite comparer les réponses afin de faire ressortir les régressions. L’idée est que « si deux implémentations du service retournent des réponses similaires pour un ensemble suffisamment large et diversifié de requêtes, alors les deux implémentations peuvent être considérées comme équivalentes et la mise en œuvre récente libre de régression. »

Plus précisément, il y a trois instances qui entrent en jeu ici. Une instance candidate qui exécute le nouveau code, une instance primaire qui exécute l’ancien code en bon état et une instance secondaire qui exécute également l’ancien code comme l’instance primaire. Les instances primaire et secondaire devraient normalement fournir les mêmes réponses puisqu’elles exécutent le même code, mais il peut arriver que les réponses diffèrent à cause d’un comportement non déterministe, ce qui est attendu selon Twitter. Diffy mesure donc la fréquence à laquelle les instances primaire et secondaire ne concordent pas les unes avec les autres qu’il compare à la fréquence à la laquelle les instances primaire et candidate ne concordent pas les unes avec les autres. « Si ces mesures sont à peu près les mêmes, alors Diffy détermine qu'il n'y a rien de mal », alors les deux implémentations sont équivalentes, donc il n’y a aucune régression.

L’outil vise en particulier les architectures orientées services comme la plateforme de Twitter qui voient un grand nombre d’évolutions à un rythme très rapide. Les nouvelles fonctionnalités ajoutées, en modifiant le code existant pourraient « casser » quelque chose. Selon l’entreprise, les tests unitaires offrent une certaine confiance pour détecter s’il y a un problème après la nouvelle implémentation, « mais l'écriture de bons tests peut prendre plus de temps que d'écrire le code lui-même. En plus, les tests unitaires offrent une couverture pour de petits segments de code à faible portée, mais ne traitent pas le comportement global d'un système composé de plusieurs segments de codes ».

Le système devenant de plus en plus complexe avec des mises à jour fréquentes, « il devient très rapidement impossible d'obtenir une couverture adéquate en utilisant des tests écrits à la main, et il y a un besoin de techniques automatisées les plus avancées qui nécessitent un minimum d'effort des développeurs. Diffy utilise une telle approche que nous utilisons », ajoute Twitter.

L’outil open source permet de détecter automatiquement les bugs dans Apache Thrift et les services basés sur HTTP. Il est publié sous la licence Apache Version 2.0.

Sources : Blog Twitter, GitHub

Et vous ?

:fleche: Que pensez-vous de cet outil qui permet de détecter automatiquement les bugs dans les codes ?

Cela ne détecte pas les bugs et c'est limité.
Cela peut, dans la limite de l'incertitude et des probabilités non déterministes, permettre de mettre en évidence une régression.

Cela ne s'applique qu'aux codes serveur vu que ce sont les retours HTTP qui sont comparés.
Ensuite j'aimerai bien voir comment ça se dépatouille quand on a une page avec des éléments variants. Cela nous explose-t-il à la figure ?
Ou peut-on fixer des règles d'exclusions ?

Enfin sachant que la majorité des sites possèdent des algorithmes assez simple je doute de l'utilité primordiale d'un tel outil.

Bref c'est un bel outil, mais c'est pas pour autant que je l'utiliserai. :?

Donc si je résume, c'est juste un outil d'exécution de tests cases, comme il en existe d'autres (Selenium, WebTest ...), sauf que là il compare les résultats de l'ancien et du nouveau code.
J'avoue ne pas être trop convaincu : l'argument par rapport aux tests unitaires est mauvais, car il s'agit là de jouer des tests d'interface, qui couvrent donc un plus large périmètre.
Pour moi, cette application est plus à mettre dans la catégorie "ceinture + bretelles" que comme socle pour bâtir une vraie stratégie de test.

Il faudrait voir si ce tool permet de générer des tests unitaires à la volée, ça permettrait un gain de temps et un panel plus large de tests, au lieu de se limiter à 2 ou 3 tests par méthode (failure, success, autre).

Citation:

---

Envoyé par Bono_BX

Donc si je résume, c'est juste un outil d'exécution de tests cases, comme il en existe d'autres (Selenium, WebTest ...), sauf que là il compare les résultats de l'ancien et du nouveau code.

---

Pas tout à fait non : ici, tu ne compares pas les différences entre 2 exécution (j'avais 10 erreurs, j'en ai 8, donc c'est mieux), mais les différences entre la comparaison de l'ancien et du nouveau d'une part, et deux anciennes instances : si entre les deux anciennes instances on a 3% de différences entre les réponses (timestamp, clef uniques, ...), et entre l'ancien et le nouveau code on a aussi 3% de différences entre les réponses, alors si on a passé un jeu de donnée suffisamment grand, on peut raisonnablement estimer (d'un point de vue mathématiques) qu'il n'y a pas plus d'erreur dans le nouveau code que dans l'ancien.

Ce n'est pas du tout comme les tests unitaires ou les tests de bout en bout, qui évaluent si un comportement donné est toujours valable (3+2 = 5, login/pass avec un mauvais mot de passe te jette avec tel message d'erreur, ...).

Je pense que ce genre de tests est très intéressant sur le papier, mais je ne suis pas certain que ça soit facilement applicable à tous les projets, donc je vais creuser avant de proposer ça à mon équipe :)

[Edit] modif car j'ai compris en lisant l'article de blog

@gangsoleil : OK, je n'avais pas vu ça comme un outil de "comparaison statistique". Je pensais que la réduction du bruit était justement une réduction des cas de tests proposés à l'outil. Effectivement, vu comme cela, je suis d'accord avec toi, je ne pense pas que ce soit applicable à tous les projets. Seulement à ceux pouvant se permettre d'avoir une marge d'erreur non impactante.
Exemple : si un tweet sur 100 ne passe pas => 1% d'erreur => l'utilisateur peut retweeter. Le but est que le nouveau code reste à 1% d'erreur.

J'ai bon ?

Citation:

---

Envoyé par Bono_BX

Exemple : si un tweet sur 100 ne passe pas => 1% d'erreur => l'utilisateur peut retweeter. Le but est que le nouveau code reste à 1% d'erreur.

J'ai bon ?

---

J'aurai plus vu ça comme ça :
L'utilisateur toto soumet (pour test) : "The quick brown fox jumps over the lazy dog"(*), et le serveur (en mode debug ?) trace "Message de toto, à 15h41m12s, <The quick brown fox jumps over the lazy dog>".
Le texte que j'ai mis en rouge est variable, et va donc varier entre les deux implémentations de référence. Cela fait une différence entre les 2 messages de X% (à vous de calculer le X).

Maintenant, on fait la même requête sur le nouveau serveur, qui change le log et contient un bug qui coupe la fin de la phrase : "Message de "toto", à 15h41m12s, <The quick brown fox jumps over the lazy>".
Ici, la différence est de 2X, qui est trop différent de X, donc il y a probablement un soucis.
En revanche, si tu avais "Message de toto, à 16h24m13s, <The quick brown fox jumps over the lazy dog>"., tu aurais toujours X% de différence, donc statistiquement, tout va bien.


(*)[Servez à ce monsieur une bière et des kiwis]

Cet outil sert plus à détecter la non régression qu'à autre. C'est donc très limité par rapport à l'ensemble des tests à faire.

Encore pire, cela n'aide certainement pas à trouver et à résoudre des bugs. Si un bug persiste alors Diffy ne le détectera pas vu que le comportement ne bougera pas suffisamment sur ce point (toujours aussi bogué). Si un bug est résolu alors le comportement va varier mais Diffy ne saura pas dire si c'est en bien ou en mal.

Perso je vois des choses intéressantes dans cette approche.
Tout d'abord, je pense qu'on peut pas demander à ce genre d'outil à lui seul de remplacer tous les types de tests imaginables (unitaires, intégration). Par contre on peut lui reconnaître qu'une série de comparaisons basées sur une version de référence "stable" et une version "rc" n'est pas complètement impertinente, surtout si l'on a travaillé que sur les couches profondes de son service (ce qui m'arrive souvent).
Ce que je trouve particulièrement intéressant, c'est que ce genre de test est plutôt facile et rapide à mettre en oeuvre, il suffit de 2 instances avec les mêmes données sources au moment T. En plus on peut raisonnablement supposer que ce type de test ne demande que très peu de maintenance puisque les assertions sont basées sur les différences par rapport à la version de référence et non sur des scénarios comme pour des tests d'intégration.

Donc c'est sans doute pas la panacée, mais je trouve que le ratio efficacité par rapport à l'effort (la fameuse règle des 80-20) peut être assez considérable. On demande pas forcément à cet outil d'être la seule et unique stratégie de test d'un service, par contre ce qu'il permet de révéler peut être bon à prendre par rapport à ce qu'il coûte.

Pour ma part, je pense que cet outil s'intègre dans une logique de déploiement continu surtout.

Écrire tous les tests est presque inacceptable d'un point de vue budgétaire pour la plupart des projets.
Les tests unitaires sont relativement bien compris des décideurs, mais les autres tests fonctionnels qui sont souvent plus long à réaliser et à exécuter sont difficile de mon point de vue à justifier sur pas mal de projet. (que ce soit pour respecter les délais de livraisons ou le budget)

Au final, ce genre de choses, si les tests sont générés automatiquement, peuvent permettre de gagner pas mal de temps.

il faut voir comment se comporte l'outil en cas de gros refactoring, ou de nouvelle version majeure, mais d'un point de vue déploiement continu poussé(plusieurs déploiement par jour) ces différences devraient rester minimes puisque l'on privilégient fortement l'ajout de fonctionnalités pas à pas et non les paliers.

Après, ca demande quand même de pouvoir faire tourner 3 instances de son application juste pour des tests, ce qui n'est pas donné. Des VM ca coute pas trop cher, mais c'est pas gratuit non plus.