Données de test : Attention aux pièges !

Lorsqu'on teste, on a souvent besoin de données factices. Dans ce post, ce que j'appelle "données factices" sont des octets quelconques, sans sens particulier. Dans un certain nombre de cas, le contenu n'a pas d'importance, comme dans l'exemple suivant :

// Testons les fonctions write(file, dataToWrite) et 
// read(file, outputBuffer) 
// On devrait pouvoir lire ce qu'on vient d'écrire
// dans FILE_1
testData = { ??? }
write(FILE_1, testData)
read(FILE_1, readData)
// Vérification que testData et readData
// contiennent la même chose
assertEquals(testData, readData)

read et write ne se préoccupent pas des données qu'elle manipulent. Ce cas de test fonctionne quel que soit la valeur de testData. Est-ce que cela signifie qu'on prendre n'importe quoi ? Certainement pas.

Remplissage avec des zéros

testData = {0, 0, 0, ... }

Le remplissage avec des zéros est le comportement par défaut dans un certain nombre de langages. Par exemple, en Java :

testData = new byte[10];
// testData vaut {0, 0, 0, 0, 0, 0, 0, 0, 0, 0}

On peut utiliser n'importe quel contenu pour ce test, alors pourquoi s'embêter ? Pour répondre à cette question, reformulons le problème. read et write peuvent être bugguées. Nous avons un test pour ça. Le seul élément qui nous manque est testData. La question devient :

• Y a-t-il un bug potentiel qui pourrait échapper à notre test en raison du choix de testData ?
• Quelle est la probabilité de ce bug ?

On pourrait imaginer plusieurs implémentations. Celle-ci est suffisante :

write(file, dataToWrite) {
  // TODO
}

read(file, outputBuffer) {
  // TODO
}

En fait... read et write ne sont pas implémentées. Elles ne font rien et attendent qu'un développeur bienveillant les code. Si le produit est livré en l'état, on peut s'attendre à un bug à moment ou à un autre !

Évidemment, notre test devrait repérer cette erreur grossière. Que se passe-t-il si on l'exécute ? Rien. Il s'achève en un "PASSED" tout à fait rassurant. testData est rempli avec des zéros et il en est de même pour readData dans un langage comme Java si on ne prend pas la précaution de l'initialiser (et pourquoi le ferait-on ? read est supposé l'écrire après tout). Par conséquent, l'assertion finale compare deux tableaux identiques ({0, 0, ...}) et passe.

Le pattern "zero" est vraiment, vraiment mauvais. Au suivant !

Remplissage avec une unique valeur

testData = {0x95, 0x95, 0x95, ... }

Le zéro était une mauvaise idée. Qu'en est-il d'une autre valeur ? Même approche, voici le bug :

write(file, dataToWrite) {
  // TODO
}

read(file, outputBuffer) {
  fill(outputBuffer, 0x95)
}

A nouveau, le bug est facile à obtenir : write ne fait rien et read remplit le buffer avec 0x95, peu importe ce qu'on lui demande. Cependant, la situation est bien différente de l'exemple précédent. Oublier d'implémenter deux fonctions est une erreur tout à fait plausible. Mais que penser de fill(outputBuffer, 0x95) dans la seconde version ? Cette instruction est étrange. C'est plus qu'un oubli ou une incompréhension du développeur. L'hypothèse du programmeur compétent dit que cette erreur est peu probable.

Bien, une valeur non-nulle est meilleure que zéro, mais est-elle bonne pour autant ? Non, toujours pas :

write(file, dataToWrite) {
  for i = 0... dataToWrite.length - 1 {
    internalBuffer[file][i] = dataToWrite[0]
  }
}

read(file, outputBuffer) {
  for i = 0... dataToWrite.length - 1 {
    outputBuffer[i] = internalBuffer[file][i]
  }
}

Cette fois-ci, read et write font quelque chose de sensé. write copie les données dans un buffer interne et read fait l'opération inverse. Mais une fois encore, il y a un bug, tout à fait plausible cette fois-ci : au lieu de prendre l'octet à l'offset i, write copie toujours le premier octet de dataToWrite. Et comme tous les octets de dataToWrite sont identiques dans notre test, le bug ne sera pas découvert.

Le pattern basé sur une répétition est un mauvais choix pour une situation type "système de fichier" comme celle-ci. En plaçant tous les octets sur un plan d'égalité, il tend à annuler les nombreuses erreurs d'offset et longueur qui peuvent se produire.

Valeur = Index

testData = {0, 1, 2, ... }

Utiliser une seule valeur n'est pas efficace. L'étape suivante est d'utiliser plusieurs valeurs. Un tableau du type {0, 1, 2, ... } pourrait être un bon candidat. Il a l'avantage d'être facile à construire :

for i = 0... testData.length - 1 {
  testData[i] = i
}

Et... voici le bug :

write(file, dataToWrite) {
  for i = 0... dataToWrite.length - 1 {
    internalBuffer[file][i] = dataToWrite[i]
  }
}

read(file, outputBuffer) {
  for i = 0... dataToWrite.length - 1 {
    outputBuffer[i] = i
  }
}

Au lieu de copier le contenu de internalBuffer[file], read prend i, l'offset lui-même. Dans ce simple exemple, le développeur n'a que peu de chances de se tromper de la sorte. Dans un vrai système cela peut facilement se produire et on ne peut pas se permettre de passer à côté.

La racine du problème est la relation entre le contenu de testData et un autre facteur utilisé dans le code (l'offset i dans cet exemple). Une erreur du programme peut ainsi échapper au test parce que le choix de testData suit le même chemin.

Données aléatoires

testData = {random(), random(), random(), ... }

Remplir testData avec des données aléatoires est la première bonne proposition. Les octets ne sont pas constants ou liés à quelque chose comme l'offset, la longueur du fichier ou un identifiant. Cela prévient le risque de confusion. Je n'ai aucun exemple de bug réaliste cette fois-ci.

Les valeurs aléatoires soulèvent des questions et engendre parfois des débats sans fin. Le test ne produira jamais deux fois le même testData d'une exécution à l'autre. Si un bug est découvert, il pourrait ne plus être détecté lors de l'exécution suivante. Pour cette raison, les données aléatoires ont leurs détracteurs. Il existent des solutions de rechange, à discuter dans un autre post.