La meilleure façon de restaurer la base de données à l'état connu entre les tests d'intégration FlexUnit4?

Question

Contexte:

J'ai une application web Flex qui communique avec un back-end Java via BlazeDS. Le client Flex est composé d'un module client flex, qui détient les vues et les modèles de présentation et un module de service flex séparé qui contient les modèles (objets de valeur) et des objets de service.

Je suis en train d'écrire des tests d'intégration asynchrones pour les RemoteObjects du module de service flexible en utilisant FlexUnit4. Dans certains des essais, je modifie les données de test et l'interroger pour voir si tout fonctionne (une technique montré ici: http://saturnboy.com/2010/02/async-testing-with-flexunit4 )

Question:

Comment puis-je sur la réinitialisation la base de données à un état connu avant chaque méthode d'essai FlexUnit4 (ou chaîne de méthode d'essai)? Dans mes tests d'intégration Java serveur, je l'ai fait par une combinaison des opérations de DbUnit et Spring test - qui rollback après chaque méthode d'essai. Mais ces intégration FlexUnit portée de multiples demandes et ainsi de multiples transactions.

Court de mettre en œuvre une API de test d'intégration de services sur le back-end, comment cela peut être accompli. Certes, d'autres se sont heurtées à cela aussi? Des questions similaires ont été posées avant ( base de données Rollback après intégration (Selenium) Tests ) , mais sans réponse satisfaisante.

Answer 1

Il y a plusieurs options:

1. Si vous utilisez des séquences pour les clés primaires: Une fois la base de données a été chargé avec les données de test, supprimez le générateur de séquence et le remplacer par celui qui commence par -1 et compte à rebours. Après le test, vous pouvez supprimer des objets avec une clé primaire <0. Pauses pour les tests qui modifient les données existantes.

   Une approche similaire est de créer un utilisateur spécial ou, si vous avez created colonnes d'horodatage, les données initiales doivent être avant une date dans le passé. Cela a besoin d'indices supplémentaires, cependant.

2. Utilisez une base de données sur le serveur qui peut être effacé rapidement ( H2 , par exemple). Ajouter une API de service que vous pouvez appeler à partir du client pour réinitialiser le DB.

3. Ajoutez à annuler votre application Web. C'est tout à fait un effort, mais une caractéristique très cool.

4. Utilisez une base de données qui permet de se déplacer dans le temps avec une seule commande, comme Lotus Notes.

5. Ne pas utiliser une base de données du tout. écrire à la place d'un serveur proxy qui répondra à l'entrée correcte avec la sortie correcte. Ajouter un code à votre serveur réel pour écrire les données échangées dans un fichier et créer vos tests de cela.

   Ou écrire des scénarios de test qui vont à l'encontre du vrai serveur et qui créent ces fichiers. Cela vous permettra de suivre les fichiers changer lorsque vous modifiez le code sur le serveur ou client.

   Sur le serveur, écrire des tests qui font en sorte qu'il fera les modifications de DB correctes.

6. Similaire à « aucune base de données du tout », cacher tout le code qui accède à la base de données dans une couche de DB et utiliser des interfaces pour y accéder. Cela vous permet d'écrire une couche maquette qui se comporte comme la base de données réelle, mais qui enregistre les données en mémoire. Cela paraît simple mais est généralement beaucoup de travail.

Answer 2

En fonction de la taille de votre base de données de test, vous pouvez automatiser les sauvegardes propres / restaurations qui vous donne l'environnement exact que vous aviez sur chaque essai.

J'ai cette approche dans le de mes projets en cours (plate-forme différente) et nous changeons de schéma de données de test aussi des scripts avec la même approche.

Answer 3

Je suis déshydraté (mon excuse fav pour court-allées). Désolé si cette réponse est trop proche de la réponse « API de service de tests d'intégration sur le back-end » que vous ne vouliez pas.

L'équipe qui a mis en place des choix « il y a des siècles » a fait FlexUnit et des solutions créées à partir de notre architecture, dont certains ne s'appliquerait à notre infrastructure. Choses à considérer: 1) toutes nos méthodes de back-end renvoient la même classe à distance cartographié. 2) la plupart de tous nos méthodes ont une méthode abstraite que dire la méthode (ou non) exécuter une « begin transaction » au début de la méthode et une « validation de la transaction » à la fin (pas sûr de votre morceau db) .

Ce dernier est probablement pas la solution la plus orientée objet, mais voici ce que asynchrone appel de test d'unité fait: Chaque test unitaire appelle la même méthode wrapper, et nous passons dans la méthode nom / package-locale, plus le [...] args. Un beginTransaction est fait. La méthode est appelée, le passage d'un faux de la méthode pour les tests unitaires (FE pour ignorer les lignes beginTransaction et CommitTransaction), tout est géré et la classe principale de « réponse » est généré et est retourné à la méthode d'essai de l'unité. Un db-restauration est exécuté et la réponse est renvoyée à l'épreuve de l'unité.

Tous nos tests unitaires sont basés sur les transactions roulement arrière. Je ne pouvais pas vous dire des problèmes qu'ils avaient lors de la création qui jive, mais c'est ma compréhension générale de la façon dont fonctionne schtuff.

L'espoir qui aide. Compréhensible si elle ne fonctionne pas. Bonne chance, --jeremy