Je teste les résultats d'une requête. La table où les résultats sont stockés a une structure comme celle-ci: et la requête reçoit les paramètres afin de faire la recherche sur la base de la date code> et par exemple, si j'utilise les valeurs suivantes: p> La requête retournera toutes les lignes où la valeur de i récupérer les résultats de l'exécution de la requête dans une liste . Afin d'évaluer les résultats, j'utilise les valeurs des paramètres que j'ai utilisés pour vérifier si les données de la liste sont conformes à eux. J'utilise une méthode pour vérifier si la date de l'élément est entre Quelle option est correcte à faire? Si aucun, quelle sera la meilleure stratégie pour le faire? J'utilise Java pour écrire les tests, mais cette question est plus concentrée sur la manière d'écrire la méthode de test plutôt que la technologie / le cadre à utiliser. De plus, je ne peux pas modifier la requête pour ajouter une clause code> par code> (qui soulagerait beaucoup de mon travail, mais n'est pas réalisable). P> Je suis préoccupé par la meilleure pratique. Je pensais à trier les données afin que je fasse des affirmations sur deux éléments, mais je m'inquiète ensuite si je dois également tester le comparateur code> utilisé pour le tri car il peut trier la liste à tort et mon test Échec, tout en vérifiant chaque élément, cela signifie manuellement en utilisant les déclarations et
heure code> colonnes comme ceci: p>
Datefrom code>: '2015-01-01' LI>
heure de from code>: 700 li>
DateTo code>: '2015-01-03' LI>
heure à code>: 600 li>
ul>
date code> est entre
2015-01-01 code> et
2015-01-03 code>, les valeurs de
heure code> sont supérieures ou égales à 700 uniquement pour
date = 2015-01-01 code> et les valeurs de
heure code> sont moins ou égal à 600 pour
date = 2015-01-03 code>. Dans cet exemple, toutes les lignes avec
date = 2015-01-02 code> seront extraites de la source de données. P>
Datefrom code> et
DateTo code>, mais je me demande comment puis-je tester les valeurs de
heure code> et
heure à code>. J'ai les idées suivantes: p>
heure code> sur les éléments où la valeur de
date code> est égale à mon
Datefrom code> Paramètre et vérifiez si ceci La valeur est égale à
Hourrom code>. Faites des semblables pour
heure à code> mais avec la valeur maximale de ces lignes où la valeur de
date code> est égale à
DateTo code> valeur de paramètre. Li>
Date code> et
heure code>, puis vérifiez les premier et les derniers éléments de la liste. La méthode de tri à utiliser sera obtenue à partir du langage de programmation que j'utilise. Li>
ul>
si-ele code> pour les affirmations, et je ne sais pas si c'est une bonne pratique. P> P>
5 Réponses :
Les deux options que vous avez proposées sont correctes. L'option où vous triez les données sera plus facile à mettre en œuvre. P>
Il n'y a rien de mal à trier les résultats après les récupérer. C'est l'approche que je prendrais, mais la vérification de chaque ligne fonctionnerait également. P>
Allez avec l'option 1. Lorsque vous parcourez les données, enregistrez les valeurs maximales et minimales. Vous ne pouviez que traverser la liste une fois. Si votre objectif est juste de trouver une existence de données non conformes, il est possible que vous ne puissiez pas terminer la traversée à la fin si vous en trouvez déjà une. Ceci est plus efficace que le tri de la liste. Le pire des cas est O (n). P>
Je peux voir comment votre principale préoccupation peut être d'écrire un test de l'unité avec la logique la plus simple possible. Faire cela augmenterait votre niveau de confiance que lorsque le test de l'unité indique un succès ou une échec, qu'il signifie vraiment que la requête renvoie de bons ou des mauvais résultats, et non que vous avez codé un bogue dans la logique de votre test. Cela peut ne pas vous importer même d'avoir la meilleure performance absolue.
Si c'est votre cas, je propose d'utiliser votre option n ° 1 très directe, où vous vérifiez simplement chaque date / heure de séquence et échouez sur le test de l'unité. Dès que vous rencontrez une date / heure qui ne figure pas dans votre date / heure minimale / max. Mais je réglerais la méthode de comparaison de 2 ensembles de date / fois de la manière suivante pour conserver la logique de comparaison très simple: p>
concaténate et format chaque date / heure dans le format de chaîne suivant: Ceci Vous permet ensuite de garder votre logique très simple et lisible. Voici un exemple de ce que cela pourrait ressembler (vous n'avez pas spécifié, alors je suppose que votre date est une chaîne, et le temps est un nombre. Mais vous pouvez vous adapter à vos types réels): P> AAAA -MM-DD HHMM code> (par exemple:
2015-01-01 0700 code>). En d'autres termes, votre chaîne est formatée avec le rembourrage zéro requis de telle sorte qu'il aura toujours une longueur de
15 code>. Suite à ce format a précisément la propriété très pratique que si vous comparez 2 de ces chaînes à l'aide de la méthode intégrée
String.comPareTo () CODE>, il comparera vos dates avec précision. P>
Cela semble intéressant et plus utile que mes idées actuelles. Je vais tester cela demain (dimanche 8 m. Pour moi) et je vous ferai savoir comment ça s'est passé. Merci.
Étant donné que c'est une date, mieux utiliser les objets de date Java; tri ou non n'est pas important pour moi (si le nombre d'éléments de la liste n'est pas très élevé). p> p>