Mocker, stubber og faker
Skille mellom testdobler: mocker, stubber, faker og dummy-objekter, og forstå hvilken rolle de spiller i testing.
Mocker, stubber og faker er en gratis leksjon i Testing i praksis: JUnit, Mockito og integrasjonstester på CoddyKit. Dette er leksjon 1 av 4. Du kan lese valgfritt 3 leksjoner fra denne læringsstien gratis i sin helhet – deretter låser CoddyKit PRO opp alle leksjoner, samt praktisk øving med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Den er en del av læringsløpet i Testing i praksis: JUnit, Mockito og integrasjonstester, og fremdriften din synkroniseres mellom nettet og CoddyKit-appen. Kurset i Testing i praksis: JUnit, Mockito og integrasjonstester inneholder totalt 4 leksjoner.
Hva er test doubles?
Når De tester en klasse, er den ofte avhengig av andre klasser. Disse «avhengighetene» kan gjøre testing vanskelig! Test doubles er erstatningsobjekter som etterligner oppførselen til de virkelige avhengighetene.
De bidrar til å isolere koden De tester, slik at testene blir raskere, mer pålitelige og enklere å skrive.
Hvorfor trenger vi dem?
Se for Dem at De tester en klasse som sender e-post eller kommuniserer med en database. De vil ikke at testene skal:
- Faktisk sende e-post (søppelpost!).
- Bli tregere fordi de kobler seg til en ekte database.
- Avhenge av eksterne tjenester som kan være utilgjengelige.
Test doubles løser disse problemene ved å tilby kontrollerte og forutsigbare erstatninger.
Dummy-objekter: Bare plassholdere
Et dummy-objekt er den enkleste typen test double. Det sendes rundt, men brukes aldri.
Tenk på det som en obligatorisk parameter som koden ikke bryr seg om i et bestemt testscenario. Det fyller bare en plass.
- Ofte
nulleller en tom instans. - Det forventes ingen oppførsel fra objektet.
- Brukes når et argument er nødvendig, men irrelevant for testen.
Dummy-eksempel: Irrelevante data
Tenk Dem en UserService som trenger en EmailSender, men der vi i et testscenario bare bryr oss om å opprette brukeren, ikke om å sende e-post.
Her kan en null eller en enkel new EmailSender() fungere som en dummy.
interface EmailSender {
void sendEmail(String to, String subject, String body);
}
class UserService {
private EmailSender emailSender;
public UserService(EmailSender emailSender) {
this.emailSender = emailSender;
}
public boolean createUser(String username) {
// In this specific test, we don't care about emailSender
// emailSender.sendEmail(username + "@example.com", "Welcome", "Hi!");
return true; // Simplified for example
}
}
public class Main {
public static void main(String[] args) {
// Here, null acts as a dummy object for createUser test
EmailSender dummySender = null;
UserService userService = new UserService(dummySender);
boolean created = userService.createUser("testuser");
System.out.println("User created: " + created);
}
}Stub-objekter: Forhåndsdefinerte svar
Et stub-objekt gir forhåndsprogrammerte svar på metodekall under en test. Det utfører ingen reell logikk, men returnerer bestemte verdier.
Stubs er nyttige når testen trenger at en avhengighet returnerer bestemte data for å kunne fortsette.
- Returnerer faste, forhåndsbestemte verdier.
- Fokuserer på tilstandsbasert testing.
- Kontrollerer ikke samhandling, men leverer bare data.
Stub-eksempel: Faste data
La oss si at en ProductService trenger en ProductRepository for å finne produkter. En stub kan returnere et bestemt produkt uten å koble seg til en ekte database.
interface ProductRepository {
String findProductNameById(int id);
}
class ProductRepositoryStub implements ProductRepository {
@Override
public String findProductNameById(int id) {
if (id == 1) {
return "Laptop";
}
return "Unknown Product";
}
}
class ProductService {
private ProductRepository repository;
public ProductService(ProductRepository repository) {
this.repository = repository;
}
public String getProductDetails(int productId) {
return "Product: " + repository.findProductNameById(productId);
}
}
public class Main {
public static void main(String[] args) {
ProductRepository stub = new ProductRepositoryStub();
ProductService service = new ProductService(stub);
System.out.println(service.getProductDetails(1));
System.out.println(service.getProductDetails(2));
}
}Fake-objekter: Forenklede implementasjoner
Et fake-objekt har en fungerende implementasjon, men den er forenklet sammenlignet med den ekte. Det tar vanligvis snarveier som gjør det uegnet for produksjon, men perfekt for testing.
En database i minnet eller en erstatning for et filsystem er vanlige eksempler på fakes.
- Inneholder noe logikk, ikke bare forhåndsdefinerte svar.
- Simulerer virkelig oppførsel, men på en enklere måte.
- Er nyttig for enhetstester som ligner integrasjonstester.
Fake-eksempel: Database i minnet
Her er en fake UserRepository som lagrer brukere i en enkel HashMap i stedet for en ekte database. Den simulerer å legge til og finne brukere.
import java.util.HashMap;
import java.util.Map;
interface UserRepository {
void addUser(String name);
String findUser(String name);
}
class InMemoryUserRepository implements UserRepository {
private Map<String, String> users = new HashMap<>();
@Override
public void addUser(String name) {
users.put(name, name);
}
@Override
public String findUser(String name) {
return users.get(name);
}
}
class UserService {
private UserRepository repository;
public UserService(UserRepository repository) {
this.repository = repository;
}
public void registerUser(String username) {
repository.addUser(username);
}
public boolean userExists(String username) {
return repository.findUser(username) != null;
}
}
public class Main {
public static void main(String[] args) {
UserRepository fakeRepo = new InMemoryUserRepository();
UserService service = new UserService(fakeRepo);
service.registerUser("Alice");
System.out.println("Alice exists: " + service.userExists("Alice"));
System.out.println("Bob exists: " + service.userExists("Bob"));
}
}Mock-objekter: Kontrollere oppførsel
Et mock-objekt er en spesiell type stub som også registrerer samhandling. De bruker mocks til å kontrollere at en bestemt metode ble kalt på en avhengighet, med bestemte argumenter og et bestemt antall ganger.
Mocks står sentralt i atferdsdrevet testing, der De er opptatt av hvordan objektet samhandler med samarbeidspartnerne sine.
- Registrerer metodekall og argumenter.
- Gjør det mulig å kontrollere samhandling.
- Opprettes ofte av mocking-rammeverk (som Mockito!).
Mocks kontra stubs: Oppførsel eller tilstand?
Hovedforskjellen ligger i formålet:
- Stubs: Fokuserer på tilstandskontroll. De leverer dataene testen trenger for å kjøre, og testen kontrollerer tilstanden til systemet som testes.
- Mocks: Fokuserer på atferdskontroll. De kontrollerer at systemet som testes, samhandlet med avhengighetene på en bestemt måte.
De kombinerer dem ofte: En stub leverer data, og en mock kontrollerer en handling.
Test av test doubles
Hvilken type test double brukes først og fremst til å kontrollere at en bestemt metode ble kalt på en avhengighet?
Oppsummering: Familien av test doubles
Vi har sett på de ulike typene test doubles og hvorfor de er viktige for å skrive gode tester:
- Dummy: En plassholder som sendes med, men ikke brukes.
- Stub: Gir forhåndsdefinerte svar på metodekall.
- Fake: En forenklet, fungerende implementasjon.
- Mock: Kontrollerer samhandling og oppførsel.
Dette gjør det enklere å velge riktig verktøy for å isolere og teste koden effektivt. Deretter skal vi se nærmere på hvordan Mockito hjelper oss med å opprette disse mock-objektene!
Lær deg Testing i praksis: JUnit, Mockito og integrasjonstester med en AI-veileder – gratis
Skriv og kjør ekte kode i nettleseren, få umiddelbar hjelp fra en AI-veileder som er tilgjengelig døgnet rundt, og fortsett der du slapp – på nettet eller i appen.
- Kurs
- 12
- Leksjoner
- 48
Ofte stilte spørsmål
Er leksjonen «Mocker, stubber og faker» gratis?
Ja – du kan lese valgfritt 3 av leksjonene i læringsstien Testing i praksis: JUnit, Mockito og integrasjonstester, inkludert «Mocker, stubber og faker», gratis i sin helhet her på nettet. Deretter låser CoddyKit PRO opp alle leksjoner, samt interaktiv øving med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Kurset i Testing i praksis: JUnit, Mockito og integrasjonstester inneholder totalt 4 leksjoner.
Hva lærer jeg i «Mocker, stubber og faker»?
Skille mellom testdobler: mocker, stubber, faker og dummy-objekter, og forstå hvilken rolle de spiller i testing. Du øver på Testing i praksis: JUnit, Mockito og integrasjonstester med praktisk kode som du kjører direkte i nettleseren, mens en AI-veileder som er tilgjengelig døgnet rundt, svarer på spørsmålene dine mens du jobber deg gjennom leksjonen.
Trenger jeg erfaring for å begynne med Testing i praksis: JUnit, Mockito og integrasjonstester?
Ingen tidligere erfaring er nødvendig. Testing i praksis: JUnit, Mockito og integrasjonstester på CoddyKit er lagt opp for både nybegynnere og viderekomne, så De kan begynne her eller helt fra start og lære i Deres eget tempo. Dette er leksjon 1 av 4.
Hvor lang tid tar leksjonen «Mocker, stubber og faker»?
De fleste CoddyKit-leksjoner tar omtrent 5–10 minutter. Hver leksjon er kort og interaktiv, slik at De gjør jevne fremskritt og kan fortsette akkurat der De slapp – både på nettet og i appen.
Kan jeg skrive og kjøre kode i denne Testing i praksis: JUnit, Mockito og integrasjonstester-leksjonen?
Ja. Alle Testing i praksis: JUnit, Mockito og integrasjonstester-leksjoner har en innebygd kodeeditor, slik at De kan skrive og kjøre ekte kode direkte i nettleseren og få umiddelbar tilbakemelding fra AI – uten lokal konfigurering.
Alle leksjonene i dette kurset
- Mocker, stubber og faker
- Oppretting av mocker med Mockito
- Verifisering av mock-interaksjoner
- Injisering av mocks med @Mock og @InjectMocks