Envelopper automatiquement les tests unitaires dans une transaction DB?

Question

[Edit (Haren): Duplicate]

Je suis à la recherche d'un moyen d'envelopper automatiquement mes tests d'intégration NUnit dans une transaction DB, de sorte que les modifications apportées par le test sont automatiquement annulées lorsque le test se termine. Idéalement, je décorerais certaines méthodes de test avec un attribut personnalisé qui permettrait à NUnit de créer une transaction au début du test et de l'annuler à la fin du test ... Je peux écrire l'attribut, mais je ne sais pas où l'ajouter un chèque pour cela. Le DB de test a une taille de 3 Go, il n'est donc pas possible de le restaurer au début de chaque test. Je sais que je peux créer manuellement une transaction dans le corps de chaque test, mais je cherche quelque chose de plus élégant.

Peut-être qu'il existe un outil de réécriture d'IL (un framework AOP, peut-être) qui peut le faire pour moi? Quelqu'un a des suggestions?

Answer 1

Il existe deux recommandations. La première consiste à utiliser les attributs SetUp et TearDown pour démarrer la transaction et l'annuler lorsque vous avez terminé. La documentation de le faire dans NUnit est ici:

http://www.nunit.org/index.php?p=setup&r=2.4.8

Si vous ne voulez pas l'utiliser, l'autre option que je vois est à ce coder dans chaque méthode, mais utiliser une instance TransactionScope en utilisant instruction pour créer la transaction (le fournisseur doit automatiquement s'enrôler).

Bien sûr, vous pouvez également créer l'instance TransactionScope dans les méthodes SetUp et TearDown.

Answer 2

Spring.net?

Je viens d'un arrière-plan Java/JUnit, mais je sais que dans Java, vous pouvez le faire en utilisant Springframework.

(Vous devrez également obtenir votre test à partir de ApplicationContext/BeanFactory afin d'y appliquer AOP).

Answer 3

N'allez-vous pas avoir des problèmes avec les transactions imbriquées ici? Comme je le comprends, la plupart des bases de données ne prennent pas en charge les transactions dans les transactions. Donc, si le code sous test utilise des transactions du tout (je pense que si vous utilisez une base de données qui supporte les transactions, vous les utiliserez), alors ce que vous voulez vraiment, ce sont des transactions imbriquées, Les bases de données ne prennent pas directement en charge.