Python Mock-objekt: En omfattande guide till Test Double-implementering

I dagens moderna programvaruutveckling är kodskrivning bara halva jobbet. Att säkerställa att koden är tillförlitlig, robust och fungerar som förväntat är den andra, lika viktiga halvan. Det är här automatiserad testning kommer in i bilden. Enhetstester är i synnerhet en grundläggande metod som innebär att man testar enskilda komponenter eller "enheter" i en applikation isolerat. Denna isolering är dock ofta lättare sagt än gjort. Verkliga applikationer är komplexa nätverk av sammankopplade objekt, tjänster och externa system. Hur kan du testa en enskild funktion om den är beroende av en databas, ett tredjeparts-API eller en annan komplex del av ditt system?

Svaret ligger i en kraftfull teknik: användningen av Test Doubles. Och i Python-ekosystemet är det primära verktyget för att skapa dem det mångsidiga och oumbärliga unittest.mock-biblioteket. Den här guiden tar dig med på en djupdykning i världen av mocks och test doubles i Python. Vi kommer att utforska "varför" bakom dem, avmystifiera de olika typerna och ge praktiska, verkliga exempel med hjälp av unittest.mock för att hjälpa dig att skriva renare, snabbare och mer effektiva tester.

Vad är Test Doubles och varför behöver vi dem?

Föreställ dig att du bygger en funktion som hämtar en användares profil från ditt företags databas och sedan formaterar den. Funktionssignaturen kan se ut så här: get_formatted_user_profile(user_id, db_connection).

För att testa den här funktionen står du inför flera utmaningar:

• Beroende av ett aktivt system: Ditt test skulle behöva en aktiv databas. Detta gör testerna långsamma, komplexa att konfigurera och beroende av ett externt systems tillstånd och tillgänglighet.
• Oförutsägbarhet: Informationen i databasen kan ändras, vilket gör att ditt test misslyckas även om din formateringslogik är korrekt. Detta gör testerna "flaky" eller icke-deterministiska.
• Svårighet att testa gränsfall: Hur skulle du testa vad som händer om databasanslutningen misslyckas eller om den returnerar en användare som saknar viss information? Att simulera dessa specifika scenarier med en riktig databas kan vara otroligt svårt.

En Test Double är en generisk term för alla objekt som ersätter ett riktigt objekt under ett test. Genom att ersätta den riktiga db_connection med en test double kan vi bryta beroendet av den faktiska databasen och ta full kontroll över testmiljön.

Att använda test doubles ger flera viktiga fördelar:

• Isolering: De låter dig testa din kodenhet (t.ex. formateringslogiken) i fullständig isolering från dess beroenden (t.ex. databasen). Om testet misslyckas vet du att problemet finns i enheten som testas, inte någon annanstans.
• Hastighet: Att ersätta långsamma operationer som nätverksförfrågningar eller databasfrågor med en test double i minnet gör att din testsvit körs dramatiskt snabbare. Snabba tester körs oftare, vilket leder till en snabbare återkopplingsslinga för utvecklare.
• Determinism: Du kan konfigurera test double för att returnera förutsägbar data varje gång testet körs. Detta eliminerar flaky tester och säkerställer att ett misslyckat test indikerar ett verkligt problem.
• Möjlighet att testa gränsfall: Du kan enkelt konfigurera en double för att simulera feltillstånd, som att generera ett ConnectionError eller returnera tom data, vilket gör att du kan verifiera att din kod hanterar dessa situationer på ett elegant sätt.

Taxonomin för Test Doubles: Bortom bara "Mocks"

Även om utvecklare ofta använder termen "mock" generiskt för att hänvisa till alla test doubles, är det bra att förstå den mer exakta terminologin som Gerard Meszaros myntade i sin bok "xUnit Test Patterns". Att känna till dessa skillnader hjälper dig att tänka tydligare på vad du försöker uppnå i ditt test.

1. Dummy

Ett Dummy-objekt är den enklaste test double. Det skickas runt för att fylla en parameterlista men används aldrig faktiskt. Dess metoder anropas vanligtvis inte. Du använder en dummy när du behöver ange ett argument till en metod, men du bryr dig inte om det argumentets beteende i samband med det specifika testet.

Exempel: Om en funktion kräver ett "logger"-objekt men ditt test inte är intresserat av vad som loggas, kan du skicka ett dummy-objekt.

2. Fake

Ett Fake-objekt har en fungerande implementering, men det är en mycket enklare version av produktionsobjektet. Det använder inte externa resurser och ersätter en lättviktsimplementering för en tungviktig. Det klassiska exemplet är en databas i minnet som ersätter en riktig databasanslutning. Den fungerar faktiskt – du kan lägga till data i den och läsa data från den – men det är bara en enkel dictionary eller lista under huven.

3. Stub

En Stub tillhandahåller förprogrammerade, "konserverade" svar på metodanrop som görs under ett test. Den används när du behöver att din kod ska ta emot specifik information från ett beroende. Du kan till exempel stubba en metod som api_client.get_user(user_id=123) för att alltid returnera en specifik användardictionary, utan att faktiskt göra ett API-anrop.

4. Spy

En Spy är en stub som också registrerar viss information om hur den anropades. Den kan till exempel registrera antalet gånger en metod anropades eller de argument som skickades till den. Detta gör att du kan "spionera" på interaktionen mellan din kod och dess beroende och sedan göra påståenden om den interaktionen i efterhand.

5. Mock

En Mock är den mest "medvetna" typen av test double. Det är ett objekt som är förprogrammerat med förväntningar på vilka metoder som kommer att anropas, med vilka argument och i vilken ordning. Ett test som använder ett mock-objekt misslyckas vanligtvis inte bara om koden som testas ger fel resultat utan också om den inte interagerar med mock på det exakt förväntade sättet. Mocks är bra för beteendeverifiering – att säkerställa att en specifik sekvens av åtgärder inträffade.

Pythons unittest.mock-bibliotek tillhandahåller en enda, kraftfull klass som kan fungera som en Stub, Spy eller Mock, beroende på hur du använder den.

Vi introducerar Pythons kraftpaket: Biblioteket `unittest.mock`

unittest.mock är en del av Pythons standardbibliotek sedan version 3.3 och är den kanoniska lösningen för att skapa test doubles. Dess flexibilitet och kraft gör det till ett viktigt verktyg för alla seriösa Python-utvecklare. Om du använder en äldre version av Python kan du installera det bakåtporterade biblioteket via pip: pip install mock.

Bibliotekets kärna kretsar kring två nyckelklasser: Mock och dess mer kapabla syskon, MagicMock. Dessa objekt är utformade för att vara otroligt flexibla och skapa attribut och metoder direkt när du använder dem.

Djupdykning: Klasserna `Mock` och `MagicMock`

`Mock`-objektet

Ett `Mock`-objekt är en kameleont. Du kan skapa ett, och det kommer omedelbart att svara på alla attributåtkomster eller metodanrop och returnera ett annat Mock-objekt som standard. Detta gör att du enkelt kan kedja ihop anrop under installationen.

            
# I en testfil...
from unittest.mock import Mock

# Skapa ett mock-objekt
mock_api = Mock()

# Att komma åt ett attribut skapar det och returnerar en annan mock
print(mock_api.users)
# Utdata: <Mock name='mock.users' id='...'>

# Att anropa en metod returnerar också en mock som standard
print(mock_api.users.get(id=1))
# Utdata: <Mock name='mock.users.get()' id='...'>

            

              
                Copy
              
            
          

Detta standardbeteende är inte särskilt användbart för testning. Den verkliga kraften kommer från att konfigurera mock att bete sig som det objekt det ersätter.

Konfigurera returvärden och sidoeffekter

Du kan tala om för en mock-metod vad den ska returnera med hjälp av attributet return_value. Det är så du skapar en Stub.

            
from unittest.mock import Mock

# Skapa en mock för en datatjänst
mock_service = Mock()

# Konfigurera returvärdet för ett metodanrop
mock_service.get_data.return_value = {'id': 1, 'name': 'Test Data'}

# Nu när vi anropar det får vi vårt konfigurerade värde
result = mock_service.get_data()
print(result)
# Utdata: {'id': 1, 'name': 'Test Data'}

            

              
                Copy
              
            
          

För att simulera fel kan du använda attributet side_effect. Detta är perfekt för att testa din kodes felhantering.

            
from unittest.mock import Mock

mock_service = Mock()

# Konfigurera metoden för att generera ett undantag
mock_service.get_data.side_effect = ConnectionError("Failed to connect to service")

# Att anropa metoden kommer nu att generera undantaget
try:
    mock_service.get_data()
except ConnectionError as e:
    print(e)
    # Utdata: Failed to connect to service

            

              
                Copy
              
            
          

Påståendemetoder för verifiering

Mock-objekt fungerar också som Spies och Mocks genom att registrera hur de används. Du kan sedan använda en uppsättning inbyggda påståendemetoder för att verifiera dessa interaktioner.

• mock_object.method.assert_called(): Påstår att metoden anropades minst en gång.
• mock_object.method.assert_called_once(): Påstår att metoden anropades exakt en gång.
• mock_object.method.assert_called_with(*args, **kwargs): Påstår att metoden senast anropades med de angivna argumenten.
• mock_object.method.assert_any_call(*args, **kwargs): Påstår att metoden anropades med dessa argument någon gång.
• mock_object.method.assert_not_called(): Påstår att metoden aldrig anropades.
• mock_object.call_count: En heltalsegenskap som talar om hur många gånger metoden anropades.

            
from unittest.mock import Mock

mock_notifier = Mock()

# Tänk dig att detta är vår funktion under testning
def process_and_notify(data, notifier):
    if data.get('critical'):
        notifier.send_alert(message="Critical event occurred!")

# Testfall 1: Kritisk data
process_and_notify({'critical': True}, mock_notifier)
mock_notifier.send_alert.assert_called_once_with(message="Critical event occurred!")

# Återställ mock för nästa test
mock_notifier.reset_mock()

# Testfall 2: Icke-kritisk data
process_and_notify({'critical': False}, mock_notifier)
mock_notifier.send_alert.assert_not_called()

            

              
                Copy
              
            
          

`MagicMock`-objektet

En `MagicMock` är en underklass till `Mock` med en viktig skillnad: den har standardimplementeringar för de flesta av Pythons "magiska" eller "dunder"-metoder (t.ex. __len__, __str__, __iter__). Om du försöker använda en vanlig `Mock` i ett sammanhang som kräver en av dessa metoder får du ett fel.

            
from unittest.mock import Mock, MagicMock

# Använda en vanlig Mock
mock_list = Mock()
try:
    len(mock_list)
except TypeError as e:
    print(e)  # Utdata: 'Mock' object has no len()

# Använda en MagicMock
magic_mock_list = MagicMock()
print(len(magic_mock_list)) # Utdata: 0 (som standard)

# Vi kan också konfigurera den magiska metodens returvärde
magic_mock_list.__len__.return_value = 100
print(len(magic_mock_list)) # Utdata: 100

            

              
                Copy
              
            
          

Tumregel: Börja med `MagicMock`. Det är i allmänhet säkrare och täcker fler användningsfall, som att mock-objekt som används i for-loopar (kräver __iter__) eller with-satser (kräver __enter__ och __exit__).

Praktisk implementering: Dekoratorn och kontexthanteraren `patch`

Att skapa en mock är en sak, men hur får du din kod att använda den istället för det riktiga objektet? Det är här `patch` kommer in i bilden. `patch` är ett kraftfullt verktyg i `unittest.mock` som tillfälligt ersätter ett målobjekt med en mock under ett tests varaktighet.

`@patch` som dekorator

Det vanligaste sättet att använda `patch` är som en dekorator på din testmetod. Du anger sökvägen för strängen till objektet du vill ersätta.

Låt oss säga att vi har en funktion som hämtar data från ett webb-API med hjälp av det populära biblioteket `requests`:

            
# i filen: my_app/data_fetcher.py
import requests

def get_user_data(user_id):
    response = requests.get(f"https://api.example.com/users/{user_id}")
    response.raise_for_status() # Generera ett undantag för dåliga statuskoder
    return response.json()

            

              
                Copy
              
            
          

Vi vill testa den här funktionen utan att göra ett riktigt nätverksanrop. Vi kan patcha `requests.get`:

            
# i filen: tests/test_data_fetcher.py
import unittest
from unittest.mock import patch, Mock
from my_app.data_fetcher import get_user_data

class TestDataFetcher(unittest.TestCase):

    @patch('my_app.data_fetcher.requests.get')
    def test_get_user_data_success(self, mock_get):
        """Testa framgångsrik datahämtning."""
        # Konfigurera mock för att simulera ett lyckat API-svar
        mock_response = Mock()
        mock_response.json.return_value = {'id': 1, 'name': 'John Doe'}
        mock_response.raise_for_status.return_value = None # Gör ingenting vid lyckande
        mock_get.return_value = mock_response

        # Anropa vår funktion
        user_data = get_user_data(1)

        # Påstå att vår funktion gjorde rätt API-anrop
        mock_get.assert_called_once_with('https://api.example.com/users/1')

        # Påstå att vår funktion returnerade förväntad data
        self.assertEqual(user_data, {'id': 1, 'name': 'John Doe'})

            

              
                Copy
              
            
          

Lägg märke till hur `patch` skapar en `MagicMock` och skickar den till vår testmetod som argumentet `mock_get`. I testet omdirigeras alla anrop till `requests.get` inuti `my_app.data_fetcher` till vårt mock-objekt.

`patch` som en kontexthanterare

Ibland behöver du bara patcha något för en liten del av ett test. Att använda `patch` som en kontexthanterare med en `with`-sats är perfekt för detta.

            
# i filen: tests/test_data_fetcher.py
import unittest
from unittest.mock import patch, Mock
from my_app.data_fetcher import get_user_data

class TestDataFetcher(unittest.TestCase):

    def test_get_user_data_with_context_manager(self):
        """Testa att använda patch som en kontexthanterare."""
        with patch('my_app.data_fetcher.requests.get') as mock_get:
            # Konfigurera mock inuti "with"-blocket
            mock_response = Mock()
            mock_response.json.return_value = {'id': 2, 'name': 'Jane Doe'}
            mock_get.return_value = mock_response

            user_data = get_user_data(2)

            mock_get.assert_called_once_with('https://api.example.com/users/2')
            self.assertEqual(user_data, {'id': 2, 'name': 'Jane Doe'})
        
        # Utanför "with"-blocket är requests.get tillbaka till sitt ursprungliga tillstånd

            

              
                Copy
              
            
          

Ett avgörande koncept: Var ska man patcha?

Detta är den enskilt vanligaste källan till förvirring när du använder `patch`. Regeln är: Du måste patcha objektet där det slås upp, inte där det definieras.

Låt oss illustrera med ett exempel. Anta att vi har två filer:

            
# i filen: services.py
class Database:
    def connect(self):
        # ... komplex anslutningslogik ...
        return "REAL_CONNECTION"


# i filen: main_app.py
from services import Database

def start_app():
    db = Database()
    connection = db.connect()
    print(f"Got connection: {connection}")
    return connection

            

              
                Copy
              
            
          

Nu vill vi testa `start_app` i `main_app.py` utan att skapa ett riktigt `Database`-objekt. Ett vanligt misstag är att försöka patcha `services.Database`.

            
# i filen: test_main_app.py
import unittest
from unittest.mock import patch
from main_app import start_app

class TestApp(unittest.TestCase):

    # DETTA ÄR FEL SÄTT ATT PATCHA!
    @patch('services.Database')
    def test_start_app_incorrectly(self, mock_db):
        start_app()
        # Detta test kommer fortfarande att använda den RIKTIGA Database-klassen!

    # DETTA ÄR DET KORREKTA SÄTTET ATT PATCHA!
    @patch('main_app.Database')
    def test_start_app_correctly(self, mock_db_class):
        # Vi patchar 'Database' i namnrymden 'main_app'
        # Konfigurera mock-instansen som kommer att skapas
        mock_instance = mock_db_class.return_value
        mock_instance.connect.return_value = "MOCKED_CONNECTION"

        connection = start_app()

        # Påstå att vår mock användes
        mock_db_class.assert_called_once() # Instansierades klassen?
        mock_instance.connect.assert_called_once() # Anropades connect-metoden?
        self.assertEqual(connection, "MOCKED_CONNECTION")

            

              
                Copy
              
            
          

Varför misslyckas det första testet? Eftersom `main_app.py` kör `from services import Database`. Detta importerar `Database`-klassen till modulen `main_app`s namnrymd. När `start_app` körs söker den efter `Database` i sin egen modul (`main_app`). Att patcha `services.Database` ändrar det i modulen `services`, men `main_app` har redan sin egen referens till den ursprungliga klassen. Det korrekta tillvägagångssättet är att patcha `main_app.Database`, vilket är det namn som koden under testning faktiskt använder.

Avancerade Mocking-tekniker

`spec` och `autospec`: Gör Mocks säkrare

En standard `MagicMock` har en potentiell nackdel: den låter dig anropa vilken metod som helst med vilka argument som helst, även om den metoden inte finns på det riktiga objektet. Detta kan leda till tester som godkänns men döljer verkliga problem, som stavfel i metodnamn eller ändringar i ett riktigt objekts API.

            
# Verklig klass
class Notifier:
    def send_message(self, text):
        # ... skickar meddelande ...
        pass

# Ett test med ett stavfel
from unittest.mock import MagicMock

mock_notifier = MagicMock()
# Oj, ett stavfel! Den riktiga metoden är send_message
mock_notifier.send_mesage("hello") # Inget fel genereras!

mock_notifier.send_mesage.assert_called_with("hello") # Detta påstående godkänns!
# Vårt test är grönt, men produktionskoden skulle misslyckas.

            

              
                Copy
              
            
          

För att förhindra detta tillhandahåller `unittest.mock` argumenten `spec` och `autospec`.

• `spec=SomeClass`: Detta konfigurerar mock att ha samma API som `SomeClass`. Om du försöker komma åt en metod eller ett attribut som inte finns i den riktiga klassen genereras ett `AttributeError`.
• `autospec=True` (eller `autospec=SomeClass`): Detta är ännu kraftfullare. Det fungerar som `spec`, men det kontrollerar också anropssignaturen för alla mockade metoder. Om du anropar en metod med fel antal eller namn på argument genereras ett `TypeError`, precis som det riktiga objektet skulle göra.

            
from unittest.mock import create_autospec

# Skapa en mock som har samma gränssnitt som vår Notifier-klass
spec_notifier = create_autospec(Notifier)

try:
    # Detta kommer att misslyckas omedelbart på grund av stavfelet
    spec_notifier.send_mesage("hello") 
except AttributeError as e:
    print(e) # Utdata: Mock object has no attribute 'send_mesage'

try:
    # Detta kommer att misslyckas eftersom signaturen är fel (inget nyckelord 'text')
    spec_notifier.send_message("hello")
except TypeError as e:
    print(e) # Utdata: missing a required argument: 'text'

# Detta är det korrekta sättet att anropa det
spec_notifier.send_message(text="hello") # Detta fungerar!
spec_notifier.send_message.assert_called_once_with(text="hello")

            

              
                Copy
              
            
          

Bästa praxis: Använd alltid `autospec=True` när du patchar. Det gör dina tester mer robusta och mindre sköra. `@patch('path.to.thing', autospec=True)`.

Verkligt exempel: Testa en databearbetningstjänst

Låt oss knyta ihop allt med ett mer komplett exempel. Vi har en `ReportGenerator` som är beroende av en databas och ett filsystem.

            
# i filen: app/services.py
class DatabaseConnector:
    def get_sales_data(self, start_date, end_date):
        # I verkligheten skulle detta fråga en databas
        raise NotImplementedError("This should not be called in tests")

class FileSaver:
    def save_report(self, path, content):
        # I verkligheten skulle detta skriva till en fil
        raise NotImplementedError("This should not be called in tests")

# i filen: app/reports.py
from .services import DatabaseConnector, FileSaver

class ReportGenerator:
    def __init__(self):
        self.db_connector = DatabaseConnector()
        self.file_saver = FileSaver()

    def generate_sales_report(self, start_date, end_date, output_path):
        """Hämtar försäljningsdata och sparar en formaterad rapport."""
        raw_data = self.db_connector.get_sales_data(start_date, end_date)
        
        if not raw_data:
            report_content = "Ingen försäljningsdata för denna period."
        else:
            total_sales = sum(item['amount'] for item in raw_data)
            report_content = f"Total försäljning från {start_date} till {end_date}: ${total_sales:.2f}"

        self.file_saver.save_report(path=output_path, content=report_content)
        return True

            

              
                Copy
              
            
          

Låt oss nu skriva ett enhetstest för `ReportGenerator.generate_sales_report` som mockar dess beroenden.

            
# i filen: tests/test_reports.py
import unittest
from datetime import date
from unittest.mock import patch, Mock
from app.reports import ReportGenerator

class TestReportGenerator(unittest.TestCase):

    @patch('app.reports.FileSaver', autospec=True)
    @patch('app.reports.DatabaseConnector', autospec=True)
    def test_generate_sales_report_with_data(self, mock_db_connector_class, mock_file_saver_class):
        """Testa rapportgenerering när databasen returnerar data."""
        # Arrange: Konfigurera våra mocks
        mock_db_instance = mock_db_connector_class.return_value
        mock_file_saver_instance = mock_file_saver_class.return_value

        # Konfigurera databasmock för att returnera falska data (Stub)
        fake_data = [
            {'id': 1, 'amount': 100.50},
            {'id': 2, 'amount': 75.00},
            {'id': 3, 'amount': 25.25}
        ]
        mock_db_instance.get_sales_data.return_value = fake_data

        start = date(2023, 1, 1)
        end = date(2023, 1, 31)
        path = '/reports/sales_jan_2023.txt'

        # Act: Skapa en instans av vår klass och anropa metoden
        generator = ReportGenerator()
        result = generator.generate_sales_report(start, end, path)

        # Assert: Verifiera interaktionerna och resultaten
        # 1. Anropades databasen korrekt?
        mock_db_instance.get_sales_data.assert_called_once_with(start, end)

        # 2. Anropades filspararen med rätt, beräknat innehåll?
        expected_content = "Total försäljning från 2023-01-01 till 2023-01-31: $200.75"
        mock_file_saver_instance.save_report.assert_called_once_with(
            path=path, 
            content=expected_content
        )

        # 3. Returnerade vår metod rätt värde?
        self.assertTrue(result)

            

              
                Copy
              
            
          

Detta test isolerar perfekt logiken i `generate_sales_report` från databasens och filsystemets komplexitet, samtidigt som det verifierar att det interagerar med dem korrekt.

Bästa praxis för effektiv Mocking

• Håll Mocks enkla: Ett test som kräver en mycket komplex mock-konfiguration är ofta ett tecken (en "testlukt") på att enheten under testning är för komplex och kan bryta mot Single Responsibility Principle. Överväg att refaktorera produktionskoden.
• Mocka samarbetspartners, inte allt: Du bör bara mock-objekt som din enhet under testning kommunicerar med (dess samarbetspartners). Mocka inte objektet du testar självt.
• Föredra `autospec=True`: Som nämnts gör detta dina tester mer robusta genom att säkerställa att mockens gränssnitt matchar det riktiga objektets gränssnitt. Detta hjälper till att fånga upp problem som orsakas av refaktorisering.
• En Mock per test (idealiskt): Ett bra enhetstest fokuserar på ett enskilt beteende eller interaktion. Om du märker att du mockar många olika objekt i ett test kan det vara bättre att dela upp det i flera, mer fokuserade tester.
• Var specifik i dina påståenden: Kontrollera inte bara `mock.method.assert_called()`. Använd `assert_called_with(...)` för att säkerställa att interaktionen hände med rätt data. Detta gör dina tester mer värdefulla.
• Dina tester är dokumentation: Använd tydliga och beskrivande namn för dina tester och mock-objekt (t.ex. `mock_api_client`, `test_login_fails_on_network_error`). Detta gör testets syfte tydligt för andra utvecklare.

Slutsats

Test doubles är inte bara ett verktyg för testning; de är en grundläggande del av att designa testbar, modulär och underhållbar programvara. Genom att ersätta verkliga beroenden med kontrollerade substitut kan du skapa en testsvit som är snabb, pålitlig och kan verifiera varje hörn av din applikations logik.

Pythons unittest.mock-bibliotek tillhandahåller en verktygslåda i världsklass för att implementera dessa mönster. Genom att bemästra MagicMock, `patch` och säkerheten med `autospec` låser du upp möjligheten att skriva verkligt isolerade enhetstester. Detta ger dig möjlighet att bygga komplexa applikationer med tillförsikt, med vetskapen om att du har ett säkerhetsnät av exakta, riktade tester för att fånga upp regressioner och validera nya funktioner. Så fortsätt, börja patcha och bygg mer robusta Python-applikationer idag.