Voici un exemple de base de ce que doit être mon test unitaire, en utilisant qunit:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Insert title here</title>
<link rel="stylesheet" href="qunit/qunit-1.13.0.css">
<script src = "qunit/qunit-1.13.0.js"></script>
<script src = "../js/fuzzQuery.js"></script>
<script>
test("Fuzz Query Basics", function()
{
equal(fuzzQuery("name:(John Smith)"), "name:(John~ Smith~)");
equal(fuzzQuery("name:Jon~0.1"), "name:Jon~0.1");
equal(fuzzQuery("Jon"), "Jon~");
//etc
}
);
</script>
</head>
<body>
<div id="qunit"></div>
</body>
</html>
Maintenant, je pensais que c'était un peu répétitif.
Pourrait mettre toutes les entrées / sorties dans un tableau et les parcourir.
test("Fuzz Query Basics", function()
{
var equals = [
["name:(John Smith)", "name:(John~ Smith~)"],
["name:Jon~0.1", "name:Jon~0.1"],
["Jon", "Jon~"]
];
for (var i = 0; i<equals.length; i++)
{
equal(fuzzQuery(equals[i][0]), equals[i][1]);
}
}
);
Et cela fonctionne bien.
Le seul avantage auquel je peux penser pour cette deuxième méthode, c'est que s'il s'avère que vous ne voulez pas vraiment l'utiliser, equalil est plus facile de faire ce changement en un seul endroit.
En termes de lisibilité, je ne pense pas que ce soit concluant dans les deux cas, même si je préfère probablement la seconde.
En le résumant davantage, vous pouvez placer les cas d'entrée / sortie dans un fichier CSV séparé, ce qui pourrait le rendre plus facile à modifier.
La question est - quelles sont les conventions générales concernant l'écriture de ces types de tests unitaires?
Y a-t-il une raison pour laquelle vous ne devriez pas les mettre en tableaux?