django test database

Зачем тебе это ? Юниттесты они ведь потому и юниттестами называются, что тестируют поведение кода, а не production data persistence. А так - можно гонять руками из шелла, как именно - можно узнать, почитав код management-команды test.

Юниттесты они ведь потому и юниттестами называются, что тестируют поведение кода,

Ололошеньки ололо.

> Есть простой способ сделать так, чтобы тестовая база не создавалась, а тестирование шло на текущей базе?

Тебе это не надо. Shared fixtures considered harmful.

> Юниттесты они ведь потому и юниттестами называются, что тестируют поведение кода

Юниттесты потому и называются юниттестами, что тестируют только отдельный, маленький юнит кода (функцию, класс, метод) в изолированном от остальных юнитов состоянии.

Когда тебе приходится лазить в базу - неважно тестовую или нет - это строго говоря интеграционные тесты. Хотя в контексте джанги - это юниттесты.

ЗЫ. И вообще, джанговские TestCases ужасны, корявы и тормозны до невозможности, не советую ими пользоваться.

Поддерживаю анонимуса с фикстурами

> Поддерживаю анонимуса с фикстурами

Фикстуры зло по нескольким причинам - 1) это тоже shared fixtures, хоть и immutable, а зависимость между тестами - это плохо 2) из-за фикстур приходиться использовать джанговские testcases, которые очень и очень сильно тормозят по сравнению c uniitestовскими 3) поддерживать фикстуры сложно, когда меняется схема таблицы 4) когда читаешь тест, непонятно, что за объект ты используешь и какие у него вообще свойства. Моки и фабрики наше все.