3 Réponses :
Les modifications apportées dans une transaction ne sont visibles que dans ladite transaction. Enroulant également le test dans une périmètre de transaction (si possible) rendrait le test se comporter différemment de la réalité dans un aspect très critique (transactions).
Il est beaucoup préférable d'utiliser une image de base de données que vous restaurez avant chaque suite de tests. Ainsi, après la fin de la suite et que la vérification est terminée, vous déposez la base de données de test. La prochaine exécution, lors de la configuration Suite, la base de données est recréée à partir de l'image enregistrée dans un état vierge prêt à être testé. Encore mieux serait d'avoir un script qui déploie la base de données à partir de zéro et exécutez ce script pendant la configuration de la suite.
BTW n'est pas possible de restaurer à un état vierge avant chaque test. De plus génériquement n'est pas possible d'avoir de longues étapes de test individuelles et de nettoyage. Lorsque vous ajoutez plus de tests, le temps passé à restaurer la base de données à l'état de test entre les tests deviendra simplement ingérable. Les suites avec des centaines de tests sont assez courantes et des essais complets de dizaines de milliers de tests signifieraient des heures et des heures passées de restaurer simplement la base de données pour le test. Concevez votre test individuel afin qu'ils puissent être exécutés de manière indépendante, c'est-à-dire. Test N doit produire des résultats valides, même si le test N-1 a échoué.
Une autre chose à considérer est l'enquête sur l'échec, vous souhaitez que votre test échoué de quitter la base de données dans un état pouvant être étudié pour des informations significatives et Vous voulez des tests ultérieurs pour pouvoir exécuter et produire des tests ultérieurs. résultats. Parfois, ces exigences se contredisent mutuellement, mais vous devez les prendre en compte et concevoir votre test autour d'eux.
Merci pour les idées, en particulier la partie sur l'enquête sur l'échec. Je vais marquer celui-ci comme une réponse, car j'ai tendance à convenir que ce que j'ai initialement pensé, n'est pas une solution réaliste.
Vous avez sûrement sélectionné votre approche il y a longtemps, mais il vous suffit de noter que vous devriez toujours pouvoir reproduire un test échoué et peut-être passer à autre chose à l'aide d'un débogueur. Donc, je ne ferais pas de problème à retenir l'état de la base de données.
Si la quantité de données requise pour restaurer la base de données à un état connu est prohibitif de scripts Drop / Créer et vous exécutez des tests sur le développeur ou l'édition d'entreprise de SQL 2005, vous pouvez consulter Création d'un instantané de base de données du bon état et revenir à celui-ci avant chaque test. Ceci est considérablement plus rapide qu'une restauration complète, bien qu'elle puisse toujours prendre trop de temps si vous avez des centaines de tests.
Merci pour votre réponse! C'est la pratique standard de notre ministère QA. Mon objectif était de trouver une alternative légère pour les développeurs à utiliser avant que le code ne passe à QA. Je pense que nous devrons devoir aller pour "développement" -Contents pour la base de données, de sorte qu'il n'aura que suffisamment de données pour des tests rapides pendant le développement.
Cela pourrait aider: Stackoverflow.com/Questions/ 768944 / ...
Oui, je n'ai aucun problème avec le sélénium en soi. Semble être un excellent outil! Problème réside dans le renversement des modifications Le broseur piloté par le sélénium en DB.
Oh mon, comment pourrais-je manquer ça? J'ai essayé de faire une recherche approfondie avant de poster cela, mais le scénario de cette question est presque une réplique. J'ajouterai un point à ma question pour différencier de leur situation ...