Developerzy Django swego czasu nie potrafili wyobrazić sobie, że może istnieć w naszym niemałym programistycznym świecie potrzeba odpalania testów bez bazy (baz) danych. Minęły trzy lata i zaserwowali nam w końcu (1.2) możliwość zdefiniowania własnego test runnera w prosty sposób (class based).

Prymitywny test runner bez bazy danych:

class NoDbTestRunner(DjangoTestSuiteRunner):
  """ A test runner to test without database creation """

  def setup_databases(self, **kwargs):
    """ Override the database creation defined in parent class """
    pass

  def teardown_databases(self, old_config, **kwargs):
    """ Override the database teardown defined in parent class """
    pass

który podpina się w settings równie trywialnie:

TEST_RUNNER = 'testrunner.NoDbTestRunner'

Pal sześć, że potrzebuję suite do testów z bazą równocześnie z suite bez niej, i żeby to osiągnąć będę musiał się jeszcze sporo napocić dorabiając najlepiej wykrywanie potrzeby użycia testowych baz. Najgorsze jednak w tym wszystkim jest to, że połączenia testowe tworzone są przez defaultowy test runner, który właśnie wywaliliśmy w kosmos. Jeśli myślicie, że brak jego odpalenia będzie skutkował brakiem zdefiniowanych połączeń i wyjątkami, to jesteście w błędzie. Oryginalny test runner ZAMIENIA parametry definicji ISTNIEJĄCYCH połączeń.

Skutkiem tego jest uruchamianie testów na ustawieniach defaultowych. A czy wiecie co robi Django przy wczytwaniu fixturek do testów? Flush DB. Dziękuję Ci, Django. Mam nadzieję, że teraz nie odpalicie NoDbTests na swoich serwerach live.

Fatalny ORM i, jak się okazuje, fatalne rozwiązanie frameworka testowego w Django zaczynają przekonywać mnie do skierowania się w stronę innego produktu, szczególnie gdy realizuje się systemy większe niż "przeciętny blogasek".