Comment faites-vous un test unitaire lorsque les résultats varient?

Question

Je construis une application qui interroge un service Web. Les données de la base de données varient et changent avec le temps. Comment créer un test unitaire pour ce type d’application?

Le service Web renvoie xml ou une page HTML sans résultats de recherche. Je ne peux pas vraiment changer le service Web. Mon application interroge essentiellement le service Web à l'aide de HTTPURLConnection et obtient la réponse sous forme de chaîne.

J'espère que cela vous aidera avec plus de détails.

Answer 1

Résumez le service Web à l’aide d’un proxy que vous pouvez simuler. Demandez à votre service Web fictif de renvoyer diverses valeurs représentant des données normales et des cas de coin. Simulez également l'obtention d'exceptions du service Web. Assurez-vous que le code fonctionne dans ces conditions et que vous pouvez être raisonnablement certain qu'il fonctionnera avec les valeurs fournies par le service Web.

Regardez jMock pour se moquer de Java.

Answer 2

À proprement parler, vous ne pouvez tester que les unités qui ont un comportement déterministe .

Un test qui se connecte à un serveur Web externe est un test d'intégration .

La solution consiste à simuler HTTPURLConnection, c'est-à-dire créer une classe dans vos tests unitaires dérivée de la classe HTTPURLConnection et renvoyant un code codé en dur ou une valeur paramétrable. MODIFIER : notez que cette opération peut être effectuée manuellement, sans aucun cadre moqueur.

La classe qui interroge le serveur Web ne doit pas instancier la connexion HTTPURLC, mais la recevoir via un paramètre. Dans les tests unitaires, vous créez HTTPURLConnectionMock et vous le transmettez à la classe qui interroge le serveur Web qui l'utilisera comme si elle utilisait une véritable HTTPURLConnection. Dans le code de production, vous créez un véritable HTTPURLConnection et le transmettez à la classe.

Vous pouvez également permettre à votre HTTPURLConnectionMock de déclencher une exception IOException afin de tester les conditions d'erreur . Ayez juste une méthode pour lui dire de ne pas renvoyer le résultat, mais une exception à la prochaine demande.

Answer 3

Votre question est un peu ouverte, mais il existe certainement des options testables en utilisant simplement les informations ci-dessus:

1. Vous pouvez vérifier si la requête fonctionne. Affirmez que vous devriez récupérer un jeu de résultats non vide / non nul.
2. Vous pouvez vérifier si le résultat de la requête est un ensemble de résultats valide . Affirmez que les résultats doivent transmettre votre code de validation (à ce stade, vous savez que les données sont non nulles, non sensuelles et éventuellement utiles).
3. Si vous savez quelque chose sur la description de schéma / données de données, vous pouvez affirmer que les champs sont sensibles les uns par rapport aux autres. Par exemple, si vous obtenez un résultat avec un hélicoptère, il ne devrait pas être associé à une altitude de moins de 100 mètres ....
4. Si vous connaissez la distribution probabiliste des données, vous devriez être en mesure de collecter un ensemble de données et d’affirmer que la distribution résultante se situe dans un écart-type de ce que vous espériez voir.

Je suis sûr qu'avec plus d'informations, vous obtiendrez une pile de suggestions utiles.

Answer 4

Cela ressemble à vos tests à un niveau trop élevé. Envisagez de vous moquer de l'interface de service Web et d'écrire d'autres tests unitaires sur la couche de données qui accède à la base de données. Quelques détails supplémentaires pourraient faciliter la réponse à cette question, par exemple la situation que vous essayez de tester.

Je m'attendrais normalement à ce que les résultats d'un test unitaire ne changent pas ou du moins se situent dans la plage que vous attendez

Answer 5

Un problème que j’ai rencontré est celui des modèles de données convolués (qui signifie "merdiques"), pour lesquels vous ne pouvez jamais être sûr que les problèmes sont dus à des erreurs de code ou de données.

Un symptôme de ceci est que votre application fonctionne très bien, passe tous les tests, etc. avec des données fictives ou un nouvel ensemble de données, mais se casse terriblement lorsque vous exécutez votre application sur des données réelles.