Comment rétablir la base de données de retour à l'état initial à l'aide de dbUnit?

Je suis nouvelle dans les tests automatisés et dbUnit. Donc je voudrais avoir votre avis.

Je vais créer une suite de tests, qui sera exécuté de la manière suivante:

  • créer une mémoire de la base de données H2
  • exécuter des scripts DDL pour créer des tables
  • exécuter dbUnit pour insérer des données initiales (appelons ça de la STATE0) qui sera utilisé par tous les tests.
  • exécuter des tests

Jusqu'à il y il a l'air bien pour moi, mais ce que je ne comprends pas, comment puis-je revenir à la base de données de la STATE0 après une série de tests et changé les données?

Puis-je le faire avec dbUnit?
Ou avec autre chose?
Dois-je recréer la base de données avant chaque test?

Simple de ne pas commettre les transactions dans les tests n'est pas approprié pour moi, car les tests finira par exécuter plus d'une transaction peut être plus d'une connexion de base de données.

OriginalL'auteur Igor Mukhin | 2010-09-28

  1. 7

    DBUnit peut faire le travail de quatre automatiquement si vous écrivez votre @BeforeClass, @Before et @After méthodes correctement. E. g. dans notre projet, à l'aide de Derby, l'un de ces cas de test ressemble

    public class MyTest {
    protected static IDataSet getDataSet() throws Exception {
        URL url = MyTest.class.getClassLoader().getResource("MyDataSet.xml");
        return new XmlDataSet(new FileInputStream(url.getPath()));
    }

    private static JdbcDatabaseTester databaseTester;

    @BeforeClass
    public static void setUpClass() throws Exception {
        //Init test environment, session etc.
        databaseTester = new JdbcDatabaseTester(
                "org.apache.derby.jdbc.ClientDriver",
                "jdbc:derby://localhost:1527/myschema", 
                "username", "password");
        databaseTester.setDataSet(getDataSet());
    }

    @AfterClass
    public static void tearDownClass() {
        //Close session etc.
    }

    @Before
    public void setUp() throws Exception {
        databaseTester.onSetup();
    }

    @After
    public void tearDown() throws Exception {
        databaseTester.onTearDown();
    }

    @Test
    public void test() throws Exception { ... }
}

    Ce code met de dos (une sous-ensemble de) la DB schéma à l'état défini par MyDataSet.xml après chaque test. (Notez que, comme @Pascal commenté, la remise à zéro ne peut pas être toujours plein, si un test modifie un tableau qui n'est pas dans le jeu de données, il ne sera pas affectée par la @Before /@After méthodes.)

    Est-ce réellement "reset" de la DB? Je veux dire, si mon test insérer des données dans la table FOO et si MyDataSet.xml ne comprend pas FOO, FOO ne sera pas "réinitialisé", à droite?
    vous avez probablement raison. L'être humain, il est toujours conseillé de vérifier que si je suis en cours d'exécution des tests qui impliquent la table FOO, cette table est en fait inclus dans le jeu de données.
    éter je suis d'accord avec cela. C'est juste que le nitpicker en moi n'a pas été totalement convaincu par le libellé de la dernière phrase 🙂 +1 de toute façon.
    dans notre profession, il est presque toujours préférable à pinailler à l'avance que d'être désolé par la suite 🙂 Donc merci pour votre commentaire, j'ai mis à jour mes réponses (espérons-le) plus clair.
    I trouver, il est très clair et tout à fait exact, maintenant.

    OriginalL'auteur Péter Török

  2. 5

    Pour initialiser la base de données pour le jeu de données initial, de mettre en œuvre ces méthodes dans votre cas de test : 

    @Override
protected DatabaseOperation getSetUpOperation() throws Exception
{
    return DatabaseOperation.CLEAN_INSERT; //by default (will do DELETE_ALL + INSERT)
}

@Override
protected DatabaseOperation getTearDownOperation() throws Exception
{
    return DatabaseOperation.NONE; //by default
}

    Vous pouvez avoir les clés étrangères des contraintes si certains de vos tests d'insérer des lignes dans une table vide (non définis dans le jeu de données initial par exemple).

    Il suffit d'ajouter cette table vide dans votre jeu de données sans ligne :

    <mydb_mypopulatedtable id="1" name="toto" alias="funky"/>
<mydb_mypopulatedtable id="2" name="titi" alias="groovy"/>
<mydb_mypopulatedtable id="3" name="tutu" alias="creepy"/>

<mydb_myemptytable />

    Ici, myemptytable a une clé étrangère vers mypopulatedtable. Si myemptytable n'a pas été défini, DBUnit voudrais essayer de supprimer le mypopulatedtable, mais échouera à cause de la contrainte. Si elle est définie, DBUnit va supprimer myemptytable lignes avant.

    Été la recherche de ce depuis toujours!!!!

    OriginalL'auteur Zofren