Django-Signale meistern: Ein tiefer Einblick in Post-save- und Pre-delete-Hooks für robuste Anwendungen

In der riesigen und komplexen Welt der Webentwicklung hängt die Erstellung skalierbarer, wartbarer und robuster Anwendungen oft von der Fähigkeit ab, Komponenten zu entkoppeln und nahtlos auf Ereignisse zu reagieren. Django, mit seiner „Batteries included“-Philosophie, bietet hierfür einen mächtigen Mechanismus: das Signalsystem. Dieses System ermöglicht es verschiedenen Teilen Ihrer Anwendung, Benachrichtigungen zu senden, wenn bestimmte Aktionen stattfinden, und anderen Teilen, auf diese Benachrichtigungen zu lauschen und zu reagieren – alles ohne direkte Abhängigkeiten.

Für global agierende Entwickler, die an vielfältigen Projekten arbeiten, ist das Verständnis und die effektive Nutzung von Django-Signalen nicht nur ein Vorteil – es ist oft eine Notwendigkeit, um elegante und widerstandsfähige Systeme zu bauen. Zu den am häufigsten verwendeten und kritischsten Signalen gehören post_save und pre_delete. Diese beiden Hooks bieten unterschiedliche Möglichkeiten, benutzerdefinierte Logik in den Lebenszyklus Ihrer Modellinstanzen einzufügen: der eine unmittelbar nach der Datenpersistenz und der andere kurz vor der Datenlöschung.

Dieser umfassende Leitfaden nimmt Sie mit auf eine tiefgehende Reise in das Django-Signalsystem, wobei der Schwerpunkt speziell auf der praktischen Implementierung und den Best Practices rund um post_save und pre_delete liegt. Wir werden ihre Parameter untersuchen, uns mit realen Anwendungsfällen mit detaillierten Codebeispielen befassen, häufige Fallstricke diskutieren und Sie mit dem Wissen ausstatten, um diese leistungsstarken Werkzeuge für die Entwicklung erstklassiger Django-Anwendungen zu nutzen.

Das Signalsystem von Django verstehen: Die Grundlage

Im Kern ist das Django-Signalsystem eine Implementierung des Beobachter-Entwurfsmusters. Es ermöglicht einem „Sender“, eine Gruppe von „Empfängern“ darüber zu informieren, dass eine bestimmte Aktion stattgefunden hat. Dies fördert eine stark entkoppelte Architektur, in der Komponenten indirekt kommunizieren können, was die gegenseitigen Abhängigkeiten reduziert und die Modularität verbessert.

Schlüsselkomponenten des Signalsystems:

• Signale: Dies sind die Dispatcher. Sie sind Instanzen der Klasse django.dispatch.Signal. Django bietet eine Reihe von integrierten Signalen (wie post_save, pre_delete, request_started usw.), und Sie können auch Ihre eigenen benutzerdefinierten Signale definieren.
• Sender: Die Objekte, die ein Signal aussenden. Bei integrierten Signalen ist dies typischerweise eine Modellklasse oder eine bestimmte Instanz.
• Empfänger (oder Callbacks): Dies sind Python-Funktionen oder -Methoden, die ausgeführt werden, wenn ein Signal gesendet wird. Eine Empfängerfunktion akzeptiert bestimmte Argumente, die das Signal weitergibt.
• Verbinden: Der Prozess der Registrierung einer Empfängerfunktion mit einem bestimmten Signal. Dies teilt dem Signalsystem mit: „Wenn dieses Ereignis eintritt, rufe jene Funktion auf.“

Stellen Sie sich vor, Sie haben ein UserProfile-Modell, das jedes Mal erstellt werden muss, wenn ein neues User-Konto registriert wird. Ohne Signale würden Sie vielleicht die Benutzerregistrierungsansicht ändern oder die save()-Methode des User-Modells überschreiben. Obwohl diese Ansätze funktionieren, koppeln sie die Logik zur Erstellung des UserProfile direkt an das User-Modell oder seine Ansichten. Signale bieten eine sauberere, entkoppelte Alternative.

Beispiel für eine grundlegende Signalverbindung:

Hier ist eine einfache Darstellung, wie man ein Signal verbindet:

            # myapp/signals.py
from django.db.models.signals import post_save
from django.dispatch import receiver
from django.contrib.auth.models import User

# Eine Empfängerfunktion definieren
@receiver(post_save, sender=User)
def create_user_profile(sender, instance, created, **kwargs):
    if created:
        # Logik zum Erstellen eines Profils für den neuen Benutzer
        print(f"Neuer Benutzer '{instance.username}' erstellt. Ein Profil kann jetzt generiert werden.")

# Alternative: Manuelles Verbinden (seltener bei integrierten Signalen mit Dekorator)
# from django.apps import AppConfig
# class MyAppConfig(AppConfig):
#     name = 'myapp'
#     def ready(self):
#         from . import signals  # Importieren Sie Ihre Signale-Datei

            

              
                Copy
              
            
          

In diesem Schnipsel wird die Funktion create_user_profile als Empfänger für das post_save-Signal festgelegt, speziell wenn es vom User-Modell gesendet wird. Der @receiver-Dekorator vereinfacht den Verbindungsprozess.

Das post_save-Signal: Reagieren nach der Persistenz

Das post_save-Signal ist eines der am weitesten verbreiteten Signale von Django. Es wird jedes Mal gesendet, wenn eine Modellinstanz gespeichert wird, sei es ein brandneues Objekt oder eine Aktualisierung eines bestehenden. Das macht es unglaublich vielseitig für Aufgaben, die unmittelbar nach dem erfolgreichen Schreiben von Daten in die Datenbank ausgeführt werden müssen.

Wichtige Parameter von post_save-Empfängern:

Wenn Sie eine Funktion mit post_save verbinden, erhält sie mehrere Argumente:

• sender: Die Modellklasse, die das Signal gesendet hat (z. B. User).
• instance: Die tatsächliche Instanz des Modells, das gespeichert wurde. Dieses Objekt spiegelt nun seinen Zustand in der Datenbank wider.
• created: Ein boolescher Wert; True, wenn ein neuer Datensatz erstellt wurde, False, wenn ein bestehender Datensatz aktualisiert wurde. Dies ist entscheidend für bedingte Logik.
• raw: Ein boolescher Wert; True, wenn das Modell als Ergebnis des Ladens einer Fixture gespeichert wurde, andernfalls False. Normalerweise möchten Sie Signale ignorieren, die von Fixtures generiert werden.
• using: Der verwendete Datenbank-Alias (z. B. 'default').
• update_fields: Ein Satz von Feldnamen, die an Model.save() als update_fields-Argument übergeben wurden. Dies ist nur bei Aktualisierungen vorhanden.
• **kwargs: Platzhalter für alle zusätzlichen Schlüsselwortargumente, die übergeben werden könnten. Es ist eine gute Praxis, dies einzuschließen.

Praktische Anwendungsfälle für post_save:

1. Erstellen von zugehörigen Objekten (z. B. Benutzerprofil):

Dies ist ein klassisches Beispiel. Wenn sich ein neuer Benutzer anmeldet, müssen Sie oft ein zugehöriges Profil erstellen. post_save mit der Bedingung created=True ist dafür perfekt.

            # myapp/models.py
from django.db import models
from django.contrib.auth.models import User

class UserProfile(models.Model):
    user = models.OneToOneField(User, on_delete=models.CASCADE)
    bio = models.TextField(blank=True)
    location = models.CharField(max_length=100, blank=True)
    birth_date = models.DateField(null=True, blank=True)

    def __str__(self):
        return self.user.username + "'s Profile"

# myapp/signals.py
from django.db.models.signals import post_save
from django.dispatch import receiver
from django.contrib.auth.models import User
from .models import UserProfile

@receiver(post_save, sender=User)
def create_or_update_user_profile(sender, instance, created, **kwargs):
    if created:
        UserProfile.objects.create(user=instance)
        print(f"UserProfile für {instance.username} erstellt.")
    # Optional: Wenn Sie auch Aktualisierungen des Benutzers verarbeiten und auf das Profil übertragen möchten
    # instance.userprofile.save() # Dies würde post_save für UserProfile auslösen, falls Sie eines hätten

            

              
                Copy
              
            
          

2. Aktualisieren von Cache oder Suchindizes:

Wenn sich ein Datenelement ändert, müssen Sie möglicherweise zwischengespeicherte Versionen ungültig machen oder aktualisieren oder den Inhalt in einer Suchmaschine wie Elasticsearch oder Solr neu indizieren.

            # myapp/signals.py
from django.db.models.signals import post_save
from django.dispatch import receiver
from .models import Product
from django.core.cache import cache

@receiver(post_save, sender=Product)
def update_product_cache_and_search_index(sender, instance, **kwargs):
    # Spezifischen Produkt-Cache ungültig machen
    cache.delete(f"product_detail_{instance.pk}")
    print(f"Cache für Produkt-ID ungültig gemacht: {instance.pk}")

    # Simulieren der Aktualisierung eines Suchindex
    # In einem realen Szenario könnte dies den Aufruf einer externen Suchdienst-API beinhalten
    print(f"Produkt {instance.name} (ID: {instance.pk}) zur Aktualisierung des Suchindex markiert.")
    # search_service.index_document(instance)

            

              
                Copy
              
            
          

3. Protokollierung von Datenbankänderungen:

Zu Audit- oder Debugging-Zwecken möchten Sie vielleicht jede Änderung an kritischen Modellen protokollieren.

            # myapp/models.py
from django.db import models

class AuditLog(models.Model):
    model_name = models.CharField(max_length=255)
    object_id = models.IntegerField()
    action = models.CharField(max_length=50) # 'created', 'updated'
    timestamp = models.DateTimeField(auto_now_add=True)
    changes = models.JSONField(blank=True, null=True)

    def __str__(self):
        return f"[{self.timestamp}] {self.model_name}({self.object_id}) {self.action}"

class BlogPost(models.Model):
    title = models.CharField(max_length=255)
    content = models.TextField()
    published_date = models.DateTimeField(auto_now_add=True)

    def __str__(self):
        return self.title

# myapp/signals.py
from django.db.models.signals import post_save
from django.dispatch import receiver
from .models import AuditLog, BlogPost # Beispielmodell zum Auditieren

@receiver(post_save, sender=BlogPost)
def log_blogpost_changes(sender, instance, created, **kwargs):
    action = 'created' if created else 'updated'
    # Bei Aktualisierungen möchten Sie möglicherweise bestimmte Feldänderungen erfassen. Erfordert einen Vergleich vor dem Speichern.
    # Der Einfachheit halber protokollieren wir hier nur die Aktion.
    AuditLog.objects.create(
        model_name=sender.__name__,
        object_id=instance.pk,
        action=action,
        # changes=previous_state_vs_current_state # Hierfür ist eine komplexere Logik erforderlich
    )
    print(f"Audit-Log für BlogPost-ID erstellt: {instance.pk}, Aktion: {action}")

            

              
                Copy
              
            
          

4. Senden von Benachrichtigungen (E-Mail, Push, SMS):

Nach einem wichtigen Ereignis, wie einer Bestellbestätigung oder einem neuen Kommentar, können Sie Benachrichtigungen auslösen.

            # myapp/models.py
from django.db import models

class Order(models.Model):
    customer_email = models.EmailField()
    status = models.CharField(max_length=50, default='pending')
    total_amount = models.DecimalField(max_digits=10, decimal_places=2)

    def __str__(self):
        return f"Order #{self.pk} - {self.customer_email}"

# myapp/signals.py
from django.db.models.signals import post_save
from django.dispatch import receiver
from .models import Order
from django.core.mail import send_mail
# from myapp.tasks import send_order_confirmation_email_task # Für asynchrone Aufgaben

@receiver(post_save, sender=Order)
def send_order_confirmation(sender, instance, created, **kwargs):
    if created and instance.status == 'pending': # Oder 'completed', wenn synchron verarbeitet
        subject = f"Bestätigung Ihrer Bestellung #{instance.pk}"
        message = f"Sehr geehrter Kunde, vielen Dank für Ihre Bestellung! Die Gesamtsumme beträgt {instance.total_amount}."
        from_email = "noreply@example.com"
        recipient_list = [instance.customer_email]

        try:
            send_mail(subject, message, from_email, recipient_list, fail_silently=False)
            print(f"Bestellbestätigungs-E-Mail an {instance.customer_email} für Bestell-ID gesendet: {instance.pk}")
        except Exception as e:
            print(f"Fehler beim Senden der E-Mail für Bestell-ID {instance.pk}: {e}")

        # Für eine bessere Leistung und Zuverlässigkeit, insbesondere bei externen Diensten,
        # sollten Sie dies an eine asynchrone Aufgabenwarteschlange (z. B. Celery) delegieren.
        # send_order_confirmation_email_task.delay(instance.pk)

            

              
                Copy
              
            
          

Best Practices und Überlegungen für post_save:

• Bedingte Logik mit created: Überprüfen Sie immer das created-Argument, wenn Ihre Logik nur für neue Objekte oder nur für Aktualisierungen ausgeführt werden soll.
• Endlosschleifen vermeiden: Wenn Ihr post_save-Empfänger die instance erneut speichert, kann er sich selbst rekursiv auslösen, was zu einer Endlosschleife und möglicherweise zu einem Stack Overflow führt. Stellen Sie sicher, dass Sie die Instanz vorsichtig speichern, vielleicht durch die Verwendung von update_fields oder durch vorübergehendes Trennen des Signals, falls erforderlich.
• Leistung: Halten Sie Ihre Signalempfänger schlank und schnell. Aufwändige Operationen, insbesondere I/O-gebundene Aufgaben wie das Senden von E-Mails oder der Aufruf externer APIs, sollten in asynchrone Aufgabenwarteschlangen (z. B. Celery, RQ) ausgelagert werden, um den Haupt-Request-Response-Zyklus nicht zu blockieren.
• Fehlerbehandlung: Implementieren Sie robuste try-except-Blöcke in Ihren Empfängern, um potenzielle Fehler ordnungsgemäß zu behandeln. Ein Fehler in einem Signalempfänger kann verhindern, dass die ursprüngliche Speicheroperation erfolgreich abgeschlossen wird, oder zumindest den Fehler vor dem Benutzer verbergen.
• Idempotenz: Entwerfen Sie Empfänger so, dass sie idempotent sind, d. h. das mehrfache Ausführen mit derselben Eingabe hat den gleichen Effekt wie eine einmalige Ausführung. Dies ist eine gute Praxis für Aufgaben wie die Cache-Invalidierung.
• Raw Saves: Normalerweise sollten Sie Signale ignorieren, bei denen raw True ist, da diese oft vom Laden von Fixtures oder anderen Massenoperationen stammen, bei denen Ihre benutzerdefinierte Logik nicht ausgeführt werden soll.

Das pre_delete-Signal: Eingreifen vor dem Löschen

Während post_save agiert, nachdem Daten geschrieben wurden, bietet das pre_delete-Signal einen entscheidenden Hook, bevor eine Modellinstanz aus der Datenbank entfernt wird. Dies ermöglicht es Ihnen, Bereinigungs-, Archivierungs- oder Validierungsaufgaben durchzuführen, die stattfinden müssen, solange das Objekt noch existiert und seine Daten zugänglich sind.

Wichtige Parameter von pre_delete-Empfängern:

Wenn Sie eine Funktion mit pre_delete verbinden, erhält sie diese Argumente:

• sender: Die Modellklasse, die das Signal gesendet hat.
• instance: Die tatsächliche Instanz des Modells, die im Begriff ist, gelöscht zu werden. Dies ist Ihre letzte Chance, auf ihre Daten zuzugreifen.
• using: Der verwendete Datenbank-Alias.
• **kwargs: Platzhalter für alle zusätzlichen Schlüsselwortargumente.

Praktische Anwendungsfälle für pre_delete:

1. Bereinigen zugehöriger Dateien (z. B. hochgeladene Bilder):

Wenn Ihr Modell ein FileField oder ImageField hat, wird das Standardverhalten von Django die zugehörigen Dateien nicht automatisch aus dem Speicher löschen, wenn die Modellinstanz gelöscht wird. pre_delete ist der perfekte Ort, um diese Bereinigung zu implementieren.

            # myapp/models.py
from django.db import models

class Document(models.Model):
    title = models.CharField(max_length=255)
    file = models.FileField(upload_to='documents/')

    def __str__(self):
        return self.title

# myapp/signals.py
from django.db.models.signals import pre_delete
from django.dispatch import receiver
from .models import Document

@receiver(pre_delete, sender=Document)
def delete_document_file_on_delete(sender, instance, **kwargs):
    # Stellen Sie sicher, dass die Datei existiert, bevor Sie versuchen, sie zu löschen
    if instance.file:
        instance.file.delete(save=False) # löscht die eigentliche Datei aus dem Speicher
        print(f"Datei '{instance.file.name}' für Dokumenten-ID: {instance.pk} aus dem Speicher gelöscht.")

            

              
                Copy
              
            
          

2. Archivieren von Daten anstelle von hartem Löschen:

In vielen Anwendungen, insbesondere solchen, die mit sensiblen oder historischen Daten umgehen, wird von einer echten Löschung abgeraten. Stattdessen werden Objekte soft-gelöscht oder archiviert. pre_delete kann einen Löschversuch abfangen und in einen Archivierungsprozess umwandeln.

            # myapp/models.py
from django.db import models

class Customer(models.Model):
    name = models.CharField(max_length=255)
    email = models.EmailField(unique=True)
    is_active = models.BooleanField(default=True)
    archived_at = models.DateTimeField(null=True, blank=True)

    def __str__(self):
        return self.name

class ArchivedCustomer(models.Model):
    original_customer_id = models.IntegerField(unique=True)
    name = models.CharField(max_length=255)
    email = models.EmailField()
    archived_date = models.DateTimeField(auto_now_add=True)
    original_data_snapshot = models.JSONField(blank=True, null=True)

    def __str__(self):
        return f"Archiviert: {self.name} (ID: {self.original_customer_id})"

# myapp/signals.py
from django.db.models.signals import pre_delete
from django.dispatch import receiver
from .models import Customer, ArchivedCustomer
from django.core.exceptions import PermissionDenied # Um das eigentliche Löschen zu verhindern
from django.utils import timezone

@receiver(pre_delete, sender=Customer)
def archive_customer_instead_of_delete(sender, instance, **kwargs):
    # Erstellen einer archivierten Kopie
    ArchivedCustomer.objects.create(
        original_customer_id=instance.pk,
        name=instance.name,
        email=instance.email,
        original_data_snapshot={
            'is_active': instance.is_active,
            'archived_at': instance.archived_at.isoformat() if instance.archived_at else None
        }
    )
    print(f"Kunden-ID: {instance.pk} archiviert anstatt gelöscht.")
    # Verhindern Sie das eigentliche Löschen, indem Sie eine Ausnahme auslösen
    raise PermissionDenied(f"Kunde '{instance.name}' kann nicht hart gelöscht, sondern nur archiviert werden.")
    # Hinweis: Für ein echtes Soft-Delete-Muster würden Sie normalerweise die delete()-Methode
    # im Modell überschreiben oder einen benutzerdefinierten Manager verwenden, da Signale eine ORM-Operation nicht einfach "abbrechen" können.
```

# myapp/models.py
from django.db import models

class Project(models.Model):
    title = models.CharField(max_length=255)
    description = models.TextField(blank=True)

    def __str__(self):
        return self.title

class Task(models.Model):
    project = models.ForeignKey(Project, on_delete=models.CASCADE)
    name = models.CharField(max_length=255)
    is_completed = models.BooleanField(default=False)

    def __str__(self):
        return self.name

# myapp/signals.py
from django.db.models.signals import pre_delete
from django.dispatch import receiver
from .models import Project, Task
from django.core.exceptions import PermissionDenied

@receiver(pre_delete, sender=Project)
def prevent_deletion_if_active_tasks(sender, instance, **kwargs):
    if instance.task_set.filter(is_completed=False).exists():
        raise PermissionDenied(
            f"Projekt '{instance.title}' kann nicht gelöscht werden, da es noch aktive Aufgaben hat."
        )
    print(f"Projekt '{instance.title}' hat keine aktiven Aufgaben; Löschvorgang wird fortgesetzt.")

            

              
                Copy
              
            
          

            # myapp/models.py
from django.db import models

class CriticalReport(models.Model):
    title = models.CharField(max_length=255)
    content = models.TextField()
    severity = models.CharField(max_length=50)

    def __str__(self):
        return f"{self.title} ({self.severity})"

# myapp/signals.py
from django.db.models.signals import pre_delete
from django.dispatch import receiver
from .models import CriticalReport
from django.core.mail import mail_admins
from django.utils import timezone

@receiver(pre_delete, sender=CriticalReport)
def alert_admin_on_critical_report_deletion(sender, instance, **kwargs):
    subject = f"KRITISCHE WARNUNG: CriticalReport ID {instance.pk} wird gleich gelöscht"
    message = (
        f"Ein kritischer Bericht (ID: {instance.pk}, Titel: '{instance.title}') "
        f"wird aus dem System gelöscht. "
        f"Diese Aktion wurde um {timezone.now()} eingeleitet." 
        f"Bitte überprüfen Sie, ob diese Löschung autorisiert ist."
    )
    mail_admins(subject, message, fail_silently=False)
    print(f"Admin-Benachrichtigung für die Löschung von CriticalReport ID gesendet: {instance.pk}")

            

              
                Copy
              
            
          

            # myapp/apps.py
from django.apps import AppConfig

class MyappConfig(AppConfig):
    default_auto_field = 'django.db.models.BigAutoField'
    name = 'myapp'

    def ready(self):
        # Importieren Sie Ihre Signale hier, um sicherzustellen, dass sie registriert sind
        # Dies verhindert zirkuläre Importe, wenn Signale auf Modelle innerhalb derselben App verweisen
        import myapp.signals # Stellen Sie sicher, dass dieser Importpfad für Ihre App-Struktur korrekt ist

            

              
                Copy
              
            
          

# Beispiel zur Vermeidung von Rekursion mit update_fields
from django.db.models.signals import post_save
from django.dispatch import receiver
from .models import Order

@receiver(post_save, sender=Order)
def update_order_status_if_needed(sender, instance, created, **kwargs):
    if created: # Nur für neue Bestellungen
        if instance.total_amount > 1000 and instance.status == 'pending':
            instance.status = 'approved_high_value'
            instance.save(update_fields=['status'])
            print(f"Bestell-ID {instance.pk} Status auf 'approved_high_value' aktualisiert (nicht-rekursives Speichern).")
```

# myapp/signals.py
from django.db.models.signals import post_save
from django.dispatch import receiver
from django.db import transaction
from .models import Photo # Angenommen, das Photo-Modell hat ein ImageField
# import os # Für tatsächliche Dateioperationen
# from django.conf import settings # Für Media-Root-Pfade
# from PIL import Image # Für Bildverarbeitung

class Photo(models.Model):
    title = models.CharField(max_length=255)
    image = models.ImageField(upload_to='photos/')

    def __str__(self):
        return self.title

@receiver(post_save, sender=Photo)
def generate_thumbnails_on_commit(sender, instance, created, **kwargs):
    if created and instance.image:
        def _on_transaction_commit():
            # Dieser Code wird nur ausgeführt, wenn das Photo-Objekt erfolgreich in die DB committet wurde
            print(f"Generiere Thumbnail für Foto-ID: {instance.pk} nach erfolgreichem Commit.")
            # Simulieren der Thumbnail-Erstellung (z. B. mit Pillow)
            # try:
            #     img = Image.open(instance.image.path)
            #     img.thumbnail((128, 128))
            #     thumb_dir = os.path.join(settings.MEDIA_ROOT, 'thumbnails')
            #     os.makedirs(thumb_dir, exist_ok=True)
            #     thumb_path = os.path.join(thumb_dir, f'thumb_{instance.image.name}')
            #     img.save(thumb_path)
            #     print(f"Thumbnail gespeichert unter {thumb_path}")
            # except Exception as e:
            #     print(f"Fehler beim Generieren des Thumbnails für Foto-ID {instance.pk}: {e}")

        transaction.on_commit(_on_transaction_commit)
```

# myapp/tests.py
from django.test import TestCase
from django.db.models.signals import post_save
from django.contrib.auth.models import User
from myapp.models import UserProfile # Angenommen, UserProfile wird durch ein Signal erstellt
from myapp.signals import create_or_update_user_profile

class UserProfileSignalTest(TestCase):

    @classmethod
    def setUpClass(cls):
        super().setUpClass()
        # Trennen Sie das Signal global für alle Tests in dieser Klasse
        # Dies verhindert, dass das Signal ausgelöst wird, es sei denn, es wird explizit für einen Test verbunden
        post_save.disconnect(receiver=create_or_update_user_profile, sender=User)

    @classmethod
    def tearDownClass(cls):
        super().tearDownClass()
        # Verbinden Sie das Signal wieder, nachdem alle Tests in dieser Klasse abgeschlossen sind
        post_save.connect(receiver=create_or_update_user_profile, sender=User)

    def test_user_creation_does_not_create_profile_without_signal(self):
        user = User.objects.create_user(username='testuser_no_signal', password='password123')
        self.assertFalse(UserProfile.objects.filter(user=user).exists())
        
    def test_user_creation_creates_profile_with_signal(self):
        # Verbinden Sie das Signal nur für diesen spezifischen Test, bei dem Sie es auslösen möchten
        # Verwenden Sie eine temporäre Verbindung, um andere Tests nicht zu beeinträchtigen, wenn möglich
        post_save.connect(receiver=create_or_update_user_profile, sender=User)
        try:
            user = User.objects.create_user(username='testuser_with_signal', password='password123')
            self.assertTrue(UserProfile.objects.filter(user=user).exists())
        finally:
            # Stellen Sie sicher, dass es danach wieder getrennt wird
            post_save.disconnect(receiver=create_or_update_user_profile, sender=User)

    def test_create_or_update_user_profile_receiver_directly(self):
        user = User.objects.create_user(username='testuser_direct', password='password123')
        self.assertFalse(UserProfile.objects.filter(user=user).exists())

        # Rufen Sie die Empfängerfunktion direkt auf
        create_or_update_user_profile(sender=User, instance=user, created=True)
        self.assertTrue(UserProfile.objects.filter(user=user).exists())

```