Une IA qui sait pourquoi elle code ?

"Generate unit tests for your code selection" 🧪

Les vendeurs d'assistants de code survitaminés à l'IA proposent tous cette fonctionnalité sous une forme ou une autre. Et, pour la plupart, c'est la seule chose qu'ils mettent en avant quand ils parlent de tests.

Ça dit beaucoup de choses sur l'état du développement logiciel. Écrire rapidement du code pourri. 💩 Enchaîner tout aussi rapidement avec des tests qui le vérifient.

Qui suggère de profiter de cette rapidité pour coder autrement ? 🔄

"Les tests, ça coute cher à écrire" 💰 Donc on les écrits après le code. Si on a le temps. On connait la chanson. 🎶 On nous la sert depuis des années pour prétendre que le TDD est trop cher.

Mais si c'était moins cher ?

Dans notre exemple, on avait poussé l'assistant de code à découpler le traitement des données de son environnement.

 1const defaultProcessStream = async (stream) => {
 2  let buffer = "";
 3  let state: "outside" | "newline" = "outside";
 4  for await (const datum of stream) {
 5    const newToken = datum.content;
 6    for (const char of newToken) {
 7      buffer += char;
 8      if (char === "`" && state !== "newline") {
 9        if (state === "outside") {
10          state = "newline";
11        }
12        buffer = "";
13      } else if (state === "newline") {
14        buffer = "";
15      }
16    }
17  }
18};

On se souvient que la démo pour un assistant de code était de "rajouter un cas inside" à l'algorithme initial. Et là, tout le monde devrait se poser deux questions :

• un cas inside, ok mais pour quoi faire ?
• mais, puisqu'on en parle, que fait ce code actuellement ?

Répondre à ces questions, c'est déjà imaginer des tests. 💡

On peut demander à un assistant ce que fait ce code. Il expliquera qu'un buffer est initialisé quand on arrive un caractère backquote '`' ou à un caractère "newline". Par contre, fournir un test, c'est moins simple. Certains répondront qu'il n'est pas testable, d'autres proposeront de modifier la fonction pour pouvoir l'observer. En fait ce code ne fait pas grand chose d'utile car on n'a aucun moyen de le vérifier sans le modifier.

Oublions l'état actuel. On veut rajouter un cas inside. Supposons un lien avec les '`'. On imagine un but pour le nouveau code.

Nous voulons traiter des flux où le contenu traité est à l'intérieur d'une paire de backquotes '`'.
Tout autre contenu est ignoré.
Démarre une séquence de TDD en écrivant un premier test et un seul avec jest.
La nouvelle fonction s'appelle newProcessStream.

 1const { newProcessStream } = require('./newProcessStream');
 2
 3describe('newProcessStream', () => {
 4  it('should extract content inside backquotes', async () => {
 5    const stream = [
 6      { content: 'This is some text `with content inside` backquotes.' }
 7    ];
 8    const result = await newProcessStream(stream);
 9    expect(result).toEqual(['with content inside']);
10  });
11});

Voilà le type de fonctionnalité qu'il serait utile de mettre en avant pour les assistants de code. Certains le font peut être mais je ne les ai pas vus.

Le gros gain de temps avec les assistants est là. Même si beaucoup n'y croient pas, écrire des tests, ça fait globalement gagner du temps. Mais là, ça en fait gagner encore plus. 🚀

Par ailleurs, vérifier qu'une IA ne fait pas une boulette sur une base de code, c'est compliqué. Vérifier que l'IA écrit correctement un test unitaire de quelques lignes, c'est immédiat.

Le bonus, c'est que si l'IA a pu écrire un test, elle saura probablement le relire et on peut donc commencer à dire que, d'une certaine manière, elle sait pourquoi elle code.