Menggunakan Database yang Sudah Ada di Django Test

Secara default, ketika menjalankan testing di Django menggunakan perintah python manage.py test, Django akan membuat database baru khusus untuk testing. Database ini biasanya diawali dengan prefix test_, lalu:

• Migrasi dijalankan
• Test dieksekusi
• Database dihapus setelah test selesai

Pendekatan ini sengaja dibuat agar test terisolasi dan tidak berisiko merusak data asli.

Namun, dalam beberapa kasus tertentu, developer ingin menggunakan database yang sudah ada saat menjalankan test. Artikel ini membahas apa yang dimaksud dengan “existing database”, bagaimana Django bekerja, opsi yang tersedia, serta risiko yang harus dipahami.

Perilaku Default Django Test

Django test runner secara default akan:

1. Membuat database test baru berdasarkan konfigurasi DATABASES
2. Menjalankan migrasi
3. Menjalankan test
4. Menghapus database test setelah selesai

Tujuan utamanya adalah memastikan:

• Test tidak saling mempengaruhi
• Data selalu dalam kondisi bersih
• Tidak ada risiko ke database production atau staging

Karena alasan inilah, Django tidak menyediakan konfigurasi langsung untuk menggunakan database production sebagai database test.

Apa yang Dimaksud “Database yang Sudah Ada”?

Istilah “existing database” bisa berarti dua hal yang berbeda:

Database Test yang Sudah Pernah Dibuat

Ini adalah database test yang sebelumnya dibuat oleh Django dan masih ada di server database.

Database Eksternal (Staging / Production)

Database yang memang sudah digunakan oleh aplikasi dan berisi data nyata.

Kedua kasus ini memiliki pendekatan dan risiko yang sangat berbeda.

Menggunakan Database Test yang Sudah Ada (--keepdb)

Jika tujuanmu adalah mempercepat proses testing, Django menyediakan opsi resmi:

python manage.py test --keepdb

Dengan opsi ini:

• Django akan menggunakan database test yang sudah ada
• Database tidak dihapus setelah test selesai
• Migrasi tidak perlu dijalankan ulang jika tidak berubah

Ini adalah cara yang aman dan direkomendasikan jika kamu hanya ingin test lebih cepat, bukan ingin memakai database production.

Menggunakan Database Eksternal untuk Test (Tidak Direkomendasikan)

Secara desain, Django tidak mendukung langsung penggunaan database eksternal (staging / production) untuk test.

Namun, dalam kondisi khusus (misalnya integration test atau legacy system), beberapa orang mencoba pendekatan berikut.

Menggunakan pytest-django dengan Database Existing

Dengan pytest-django, kamu bisa menimpa konfigurasi database saat test dijalankan.

Contoh di conftest.py:

import pytest
from django.conf import settings

@pytest.fixture(scope="session")
def django_db_setup():
    settings.DATABASES['default'] = {
        'ENGINE': 'django.db.backends.postgresql',
        'NAME': 'existing_db',
        'USER': 'readonly_user',
        'PASSWORD': 'secret',
        'HOST': 'db.example.com',
        'PORT': '5432',
    }

Dengan konfigurasi ini, test akan langsung terhubung ke database tersebut.

⚠️ Risiko besar:

• Test bisa mengubah atau menghapus data nyata
• State database tidak bisa diprediksi
• Test menjadi flaky dan sulit di-debug

Pendekatan ini hanya masuk akal untuk read-only test, bukan unit test biasa.

Risiko Menggunakan Database Existing

Menggunakan database yang sudah ada secara langsung untuk test memiliki banyak risiko:

• ❌ Data bisa berubah atau terhapus
• ❌ Test saling bergantung pada state data
• ❌ Tidak ada isolasi antar test
• ❌ Sulit melakukan rollback

Karena alasan ini, Django memilih untuk tidak mendukungnya secara default.

Alternatif yang Lebih Aman

Gunakan Fixtures

Ambil data dari database existing lalu dump ke fixture:

python manage.py dumpdata app.Model > data.json

Kemudian load saat test:

python manage.py loaddata data.json

Dengan cara ini:

• Test tetap berjalan di database terisolasi
• Data tetap realistis
• Tidak ada risiko ke database asli

Custom Test Runner

Untuk kebutuhan sangat spesifik, kamu bisa membuat custom test runner dengan meng-override:

• setup_databases
• teardown_databases

Namun pendekatan ini kompleks dan jarang benar-benar dibutuhkan.

Mocking untuk Unit Test

Untuk logic yang tidak membutuhkan database nyata:

• Gunakan mocking
• Isolasi logic bisnis
• Kurangi ketergantungan ke database

Ini membuat unit test lebih cepat dan stabil.

Ringkasan Pendekatan

Kesimpulan

Django secara default selalu membuat database test sendiri demi keamanan dan isolasi.

Jika kamu ingin menggunakan database yang sudah ada:

• Gunakan --keepdb jika hanya ingin mempercepat test
• Gunakan fixtures untuk data realistis
• Hindari menggunakan database production langsung

Pendekatan ini menjaga test tetap aman, stabil, dan sesuai dengan prinsip testing yang benar.