Wadą korzystania z transakcji jest pozbywanie się z testowaniem integracji struktury encji

Question

Poszukuję szybkiego sposobu czyszczenia danych tabel wykonujących testy integracji z EF.

Każdy wydaje się zawijać transakcję wokół swojej metody testowej i pozbywać się transakcji po teście.

W ten sposób dane nigdy nie zostaną zapisane w tabeli.

Rzeczy takie jak nowe automatyczne identyfikatory do wstawek wciąż działają, ale zadaję sobie, że ta metoda jest naprawdę niezawodna w porównaniu do transakcji .commit().

Czy są jakieś wady korzystania z tego podejścia, które nie wydają się być test prawdziwa integracja jako baza danych nie jest dotykany ...

Albo innymi słowy zapytał czy są jakieś błędne scenariusze, które nie pojawiają jako wyjątki używając transakcja bez commit()?

UPDATE

public abstract class IntegrationTestsBase 
    { 
     protected TransactionScope TransactionScope; 

     public abstract void TestSetup(); 
     protected void InitTestSetupOnTable(string tableName) 
     { 
      TransactionScope = new TransactionScope(); 

      using (var context = new TGBContext()) 
      { 
       var cmdCommand = string.Format("DBCC CHECKIDENT ({0}, RESEED, 1)", tableName); 
       context.Database.ExecuteSqlCommand(cmdCommand); 
       context.SaveChanges(); 
      } 
     } 

     [TestCleanup] 
     public void TestCleanup() 
     { 
      TransactionScope.Dispose(); 
     } 
    } 

[TestClass] 
public class MyTests : IntegrationTestsBase 
{ 
     [TestInitialize] 
     public override void TestSetup() 
     { 
      base.InitTestSetupOnTable("MyTableName");   
     } 
} 

Answer 1

jako baza danych nie jest dotykany

pewnością to dotknął. Wszystko, co dzieje się w ramach transakcji, dzieje się w bazie danych. Wartości i sekwencje tożsamości (jeśli są) są inkrementowane, wyzwalają ogień, sprawdzane są więzy referencyjne itp. Jedyne, co się dzieje, dzieje się w izolacji, a na końcu wszystko (z wyjątkiem przyrostowych tożsamości i sekwencji) zostaje odwrócone.

Czy są jakieś wady stosowania tego podejścia?

Niezupełnie. Używam tego podejścia szeroko w moim własnym kodzie i ma wielkie zalety. Zielone testy dają bardzo wysoki poziom pewności. Nigdy nie będę czuł się bezpiecznie z "prawdziwym" testem jednostkowym przy użyciu wyśmianych kontekstów i DbSet (chociaż używam testu jednostkowego dla wielu innych rzeczy).

Ale są pewne ograniczenia, o których powinieneś wiedzieć.

• Wartości tożsamości/sekwencji nie są deterministyczne, więc nie można ich potwierdzić. Jak już powiedziałem, wartości te nie zostaną wycofane. Jeśli naprawdę potrzebujesz zapewnień w tym obszarze, możesz zresetować tożsamości/sekwencje po każdym teście.
• Nie możemy nigdy przetestować problemów związanych z współbieżnością dzięki temu podejściu.
• Nie można otworzyć połączenia z inną bazą danych lub nawet z tą samą bazą danych, jeśli jej ciąg połączenia różni się najdrobniejszymi szczegółami (np. Inna nazwa aplikacji lub inne ustawienie MARS), bez wywoływania kodu DTC. W aplikacji kod byłby możliwy, ponieważ te różne połączenia nie byłyby opakowane w TransactionScope. Być może nie wszystkie ścieżki aplikacji można łatwo przetestować w ten sposób.
• Programiści powinni używać własnej kopii testowej bazy danych. Jeśli wielu programistów (i być może serwer kompilacji) uruchamia testy w tej samej bazie danych, mogą się one wzajemnie zakleszczać.