Je suis en train d'écrire un grattoir d'écran HTML. Quelle serait la meilleure façon de créer des tests d'unité pour cela?
est-il "OK" d'avoir un fichier HTML statique et de le lire à partir du disque sur chaque test?
Avez-vous des suggestions?
11 Réponses :
Je ne vois pas pourquoi il importe où le HTML provient depuis que vos tests de l'unité sont concernés. Pour clarifier: Votre test de l'unité traite le contenu HTML, où le contenu est immatériel, la lecture d'un fichier est correcte pour vos tests d'unités. Comme vous le dites dans votre commentaire, vous ne voulez certainement pas frapper le réseau pour chaque test car cela ne fait que surcharger.
Vous pouvez également ajouter un test d'intégration ou deux pour vérifier que vous traitez correctement les URL de traitement correctement (c'est-à-dire que vous pouvez connecter et traiter les URL externes).
Eh bien, je me demande quelle est la meilleure pratique dans ces situations. Je ne veux certainement pas faire une demande HTTP sur chaque test.
Vous devez probablement interroger une page statique sur le disque pour tous les tests sauf un ou deux. Mais n'oubliez pas ces tests qui touchent le Web!
Qu'est-ce que vous suggérez des sons sensibles. J'aurais peut-être un répertoire de fichiers HTML de test appropriés, ainsi que des données sur ce à quoi s'attendre pour chacun. Vous pouvez également renseigner qu'avec des pages problématiques connues comme / lorsque vous les rencontrez, pour former une suite de test de régression complète.
Vous devez également effectuer des tests d'intégration pour parler de HTTP (y compris non seulement des extratures de page réussies, mais également des erreurs 404, des serveurs insensibles, etc.)
Je dirais que cela dépend du nombre de tests différents que vous devez exécuter.
Si vous devez rechercher un grand nombre de choses différentes dans votre test de l'unité, vous risquez de générer une sortie HTML dans le cadre de votre Initialisation des tests. Il serait toujours basé sur le fichier, mais vous auriez un motif extensible: de cette façon lorsque vous ajoutez du test Zzzzz sur la route, vous auriez un moyen cohérent de fournir tester les données. Si vous voulez simplement exécuter un nombre limité de tests, et il restera de cette façon, quelques fichiers HTML statiques pré-écrits devraient être corrects. Certains Les tests d'intégration comme riche suggèrent.
Pour garantir que le test puisse être exécuté encore et encore, vous devez avoir une page statique à tester. (C.-à-d. Du disque est ok)
Si vous écrivez un test qui touche la page en direct sur le Web, ce n'est probablement pas un test de l'unité, mais un test d'intégration. Vous pourriez avoir ceux-là aussi.
Merci, cela répond à ma question.
Je dois dire que si vous enregistrez une page statique sur un disque et que le test le prend à partir du disque, il n'est toujours pas un test d'unité.
@Ocar: Non, pas de la manière absolue la plus stricte. Si vous en avez besoin, vous pouvez en faire une corde à la place ...
à Créez vos tests de l'unité, vous devez savoir comment fonctionner votre grattoir et quels types d'informations vous pensez pouvoir extraire. À l'aide de pages Web simples car des tests d'unités pourraient être corrects en fonction de la complexité de votre grattoir.
Pour les tests de régression, vous devez absolument garder des fichiers sur disque.
Mais si votre objectif ultime est de gratter le Web, vous devez également conserver un enregistrement de requêtes courantes et le HTML qui revient. De cette façon, lorsque votre application échoue, vous pouvez capturer rapidement toutes les requêtes passées d'intérêt (en utilisant Say En d'autres termes, test de régression à la fois contre HTML connu et contre le HTML inconnu des requêtes connues. Si vous publiez une requête connue et que le HTML revient est identique à celui de votre base de données, vous n'avez pas besoin de le tester deux fois.
Incidemment, j'ai eu beaucoup meilleur écran de chance grattant depuis que j'ai arrêté d'essayer de gratter HTML et démarrez plutôt de gratter la sortie de wget ou curl ) et découvrez si et comment le HTML a changé. < / p>
w3m -dump , qui est ascii et est tellement plus facile à traiter!
Vous créez une dépendance externe, qui va être fragile.
Pourquoi ne pas créer de projet TestContent, peuplé avec un tas de fichiers de ressources? Copier 'N Coller votre Source HTML dans le ou les fichiers de ressources, puis vous pouvez les référencez dans vos tests d'unité.
Vous devez penser à ce que vous grattez.
Si le HTML est statique, j'utiliserais simplement quelques copies locales différentes sur le disque. Puisque vous savez que le HTML n'est pas obligé de changer de manière drastique et de casser votre grattoir, vous pouvez écrire votre test avec confiance à l'aide d'un fichier local.
Si le HTML est dynamique (à nouveau, terme desserré), vous voudrez peut-être aller de l'avant et utiliser des demandes en direct dans le test. Si vous utilisez une copie locale dans ce scénario et que vous pouvez vous attendre à ce que le HTML en direct fasse de même, tandis que cela peut échouer. Dans ce cas, en testant à chaque fois le HTML en direct, vous savez immédiatement si votre grattoir d'écran est à la hauteur ou non, avant le déploiement.
Maintenant si vous ne vous souciez tout simplement pas de quel format le code HTML est, l'ordre des éléments ou la structure, car vous tirez simplement des éléments individuels en fonction de certains mécanismes de correspondance (regex / autre), puis une copie locale peut Sois bien, mais vous voudrez peut-être toujours vous pencher vers les tests contre HTML en direct. Si les changements HTML en direct, spécifiquement des parties de ce que vous recherchez, votre test peut passer si vous utilisez une copie locale, mais que le déploiement peut échouer.
Mon avis serait de tester contre le HTML en direct si vous le pouvez. Cela empêchera vos tests locaux de passer lorsque le HTML en direct peut échouer et VISA-VERSA. Je ne pense pas qu'il y ait une meilleure pratique avec les écrans judicieux, car les scénarios en eux-mêmes sont des buggers inhabituels. Si un site Web ou un service Web n'expose pas d'API, un screencraper est en quelque sorte une solution de contournement au fromage pour obtenir les données souhaitées.
On dirait que vous avez plusieurs composants ici:
Vous devez tester (et probablement) mettre en œuvre ces parties de grattoir de manière indépendante.
Il n'y a aucune raison pour ne pas pouvoir obtenir de contenu de n'importe où (c'est-à-dire pas http).
Il n'y a aucune raison pour ne pas vouloir éloigner la palette aux fins autres que gratter.
Il n'y a aucune raison de stocker uniquement des données dans votre base de données via la grattage.
Alors .. Il n'y a aucune raison de construire et de tester toutes ces pièces de votre code en tant que vaste vaste programme.
Puis encore ... Peut-être que nous devons compliquer des choses?
Les fichiers sont ok mais: votre grattoir d'écran traite du texte. Vous devriez avoir divers tests d'unités qui "égratigent" différents morceaux de texte codés dur dans chaque test d'unité. Chaque pièce doit "provoquer" les différentes parties de votre méthode de grattoir.
De cette façon, vous supprimez complètement les dépendances à quelque chose d'externe, à la fois des fichiers et des pages Web. Et vos tests seront plus faciles à maintenir individuellement car ils ne dépendont plus des fichiers externes. Vos tests d'unité seront également exécutés (légèrement) plus rapides;)
Pour mon rubis + Mécaniser les racleurs, j'essaye des tests d'intégration qui testent de manière transparente autant de versions possibles de la page cible que possible.
À l'intérieur des tests Je surcharge la méthode de récupération HTTP de grattoir pour rétablir automatiquement une version plus récente de la page, en plus d'une copie "originale" enregistrée manuellement. Ensuite, chaque test d'intégration fonctionne contre:
... et soulève une exception si le nombre de champs renvoyés par eux est différent, par exemple. Ils ont changé le nom d'une classe de vignettes, mais fournit toujours une certaine résilience contre les tests de décomposition car le site cible est en panne.
Cela semble très intéressant car je ne suis pas connu avec des tests d'intégration. Êtes-vous capable de fournir un exemple à cela?
Après avoir terminé cela, vous devriez le poster ici en tant que wiki communautaire. J'ai entrepris cette tâche une demi-douzaine de fois et je me retrouve toujours avec une solution différente avec des avantages et des inconvénients différents. Il serait cool de voir comment les autres sont les gens ici pour la résoudre