Django TransactionTestCase z emulacją wycofywania

Używam Django 1.7.7 z pytonem 2.7.6 i Postgresem jako bazą danych i miałem problem z TransactionTestCase. Podczas moich migracji miałem dwie datamigacje i chciałem, aby były dostępne podczas testów, więc dodałem serialized_rollback = True do mojego testu (https://docs.djangoproject.com/en/1.7/topics/testing/overview/#test-case-serialized-rollback).Django TransactionTestCase z emulacją wycofywania

Pierwszy test przypadków testowych było ok, ale potem Django narzekał z IntegrityError:

IntegrityError: duplicate key value violates unique constraint "django_content_type_app_label_6032a1f08b99c274_uniq" 
DETAIL: Key (app_label, model)=(admin, logentry) already exists.

udało mi się uruchomić testy i aby uniknąć tego błędu poprzez dodanie następujących do moich ustawień (https://docs.djangoproject.com/en/1.7/ref/settings/#std:setting-TEST_NON_SERIALIZED_APPS):

TEST_NON_SERIALIZED_APPS = ['django.contrib.contenttypes', 
          'django.contrib.auth']

Ale chciałbym wiedzieć, dlaczego jest to potrzebne? Czy jest to błąd w cofnięciu lub czy jest to problem po mojej stronie?

Źródło

2015-03-24 se7entyse7en

Po prostu pomógł mi dostać się wokół naprawdę duży problem z moim teście TransactionTestCase. Nigdy dotąd nie słyszałem o TEST_NON_SERIALIZED_APPS. DZIĘKI. Myślę, że to dlatego, że TransactionTestCase wydaje się zepsuty. Mój kod pracował z 1.7.2, zatrzymał się na 1.7.8 bez TEST_NON_SERIALIZED_APPS. Jestem (powoli) przeprowadzam się do py.test, jakoś wierzę, że instalacje pytest-django mi w tym pomogą. Ostatecznie. Moja odpowiedź na twoje pytanie? Myślę, że zrobiłeś wszystko WSZYSTKO PRAWO i cała ta gimnastyka jest wymagana z Django 1.7 ATM. – dotz

Zgadzam się, to jest pytanie i odpowiedź w jednym. Wielkie dzięki! Nie jestem pewien, dlaczego Django nie serializuje tych aplikacji domyślnie, ponieważ w moim przypadku nie działał bez TEST_NON_SERIALIZED_APPS ustawionego zgodnie z sugestią. –

Kwestia ta jest bardzo dobrze wyjaśnione w Django biletu powiązanymi: https://code.djangoproject.com/ticket/23727

Cytowany stamtąd:

Przy zastosowaniu TransactionTestCase z serialized_rollback = True, po utworzeniu bazy danych i działa jego migracje (wraz z wysyłanie sygnału post_migrate), zawartość bazy danych jest serializowana do _test_serialized_contents.

Po pierwszym przypadku testowym funkcja _fixture_teardown() będzie wypróżniać tabele, ale wtedy zostanie wysłany sygnał post_migrate, a nowe wiersze (z nowymi PKs) zostaną utworzone w tabeli django_content_type.

Następnie w kolejnych testowych przypadkach w pakiecie _fixture_setup() próbuje deserializować zawartość _test_serialized_contents, ale te wiersze są identyczne z wierszami już w bazie danych z wyjątkiem ich PK.

Powoduje to wystąpienie wyjątku IntegrityError ze względu na wyjątkowe ograniczenie w tabeli django_content_type.

Łatka została utworzona/wydana, ale tylko dla Django 1.9.x.

Na poprzednich wersjach, należy kontynuować stosowanie TEST_NON_SERIALIZED_APPS Chyba ...

Źródło

2016-02-12 10:12:31 romgar

Django TransactionTestCase z emulacją wycofywania

Odpowiedz

Powiązane problemy