9
votes

Est-il correct de trier une liste dans le corps du boîtier de test pour vérifier les données limites?

Je teste les résultats d'une requête. La table où les résultats sont stockés a une structure comme celle-ci: xxx

et la requête reçoit les paramètres afin de faire la recherche sur la base de la date et et heure colonnes comme ceci: xxx

par exemple, si j'utilise les valeurs suivantes:

  • Datefrom : '2015-01-01'
  • heure de from : 700
  • DateTo : '2015-01-03'
  • heure à : 600

    La requête retournera toutes les lignes où la valeur de date est entre 2015-01-01 et 2015-01-03 , les valeurs de heure sont supérieures ou égales à 700 uniquement pour date = 2015-01-01 et les valeurs de heure sont moins ou égal à 600 pour date = 2015-01-03 . Dans cet exemple, toutes les lignes avec date = 2015-01-02 seront extraites de la source de données.

    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 Datefrom et DateTo , mais je me demande comment puis-je tester les valeurs de heure et heure à . J'ai les idées suivantes:

    • commencer à vérifier la valeur MINUMUM de heure sur les éléments où la valeur de date est égale à mon Datefrom Paramètre et vérifiez si ceci La valeur est égale à Hourrom . Faites des semblables pour heure à mais avec la valeur maximale de ces lignes où la valeur de date est égale à DateTo valeur de paramètre.
    • Trier la liste de ma méthode de test par Date et heure , 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.

      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 par (qui soulagerait beaucoup de mon travail, mais n'est pas réalisable).

      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 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 si-ele pour les affirmations, et je ne sais pas si c'est une bonne pratique.


0 commentaires

5 Réponses :


2
votes

Les deux options que vous avez proposées sont correctes. L'option où vous triez les données sera plus facile à mettre en œuvre.


0 commentaires

2
votes

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.


0 commentaires

-1
votes

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).


0 commentaires

5
votes

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:

concaténate et format chaque date / heure dans le format de chaîne suivant: AAAA -MM-DD HHMM (par exemple: 2015-01-01 0700 ). 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 . 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 () , il comparera vos dates avec précision.

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): xxx


1 commentaires

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.



2
votes

Étant donné que c'est une date, mieux utiliser les objets de date Java; xxx

tri ou non n'est pas important pour moi (si le nombre d'éléments de la liste n'est pas très élevé).


0 commentaires