streamalism.org

1. Oversigt

Denne vejledning illustrerer forskellige anvendelser af standard statisk spotte metoder til Mockito API.

Som med andre artikler, der fokuserer på Mockito-rammen (som Mockito Verify eller Mockito When / Then), er MyList klasse vist nedenfor vil blive brugt som den samarbejdspartner, der bespottes i testsager:

offentlig klasse MyList udvider AbstractList {@Override public String get (int index) {return null; } @ Override public int-størrelse () {return 1; }}

2. Enkel hån

Den enkleste overbelastede variant af spotte metoden er den med en enkelt parameter til klassen, der skal bespottes:

offentlig statisk T-mock (Class classToMock)

Vi bruger denne metode til at spotte en klasse og sætte en forventning:

MyList listMock = mock (MyList.class); når (listMock.add (anyString ())). derefterReturn (false);

Udfør derefter en metode på mock:

boolsk tilføjet = listMock.add (randomAlphabetic (6));

Følgende kode bekræfter, at tilføje metode er blevet påberåbt på mocken, og at påkaldelsen returnerer en værdi, der svarer til den forventning, vi har sat før:

verificer (listMock) .add (anyString ()); assertThat (tilføjet, er (falsk));

3. Mocking With Mock's Name

I dette afsnit vil vi dække en anden variant af spotte metode, der er forsynet med et argument, der specificerer navnet på mock:

offentlig statisk T-mock (klasse classToMock, strengnavn)

Generelt har navnet på en mock intet at gøre med arbejdskoden, men kan være nyttigt, når det kommer til fejlfinding, hvor mockens navn bruges til at spore verifikationsfejl.

For at sikre, at det angivne navn på en mock er inkluderet i meddelelsen om en undtagelse fra en mislykket verifikation, vil vi stole på en JUnit-implementering af TestRule-interface, kaldet ExpectedException, og inkluder det i en testklasse:

@Rule public ExpectedException kastet = ExpectedException.none ();

Denne regel vil blive brugt til at håndtere undtagelser fra testmetoder.

I den følgende kode opretter vi en mock til MyList klasse og navngiv det myMock:

MyList listMock = mock (MyList.class, "myMock");

Bagefter skal du indstille en forventning om en metode til mock og udføre den:

når (listMock.add (anyString ())). derefterReturn (false); listMock.add (randomAlphabetic (6));

Vi opretter en bevidst mislykket verifikation, der skal kaste en undtagelse med meddelelsen, der indeholder oplysninger om mock. For at gøre det skal forventningerne til undtagelsen først indstilles:

throw.expect (TooLittleActualInvocations.class); throw.expectMessage (containString ("myMock.add"));

Følgende verifikation skal mislykkes og kaste en undtagelse, der svarer til det forventede:

verificer (listMock, times (2)). tilføj (anyString ());

Her er meddelelsen fra den kastede undtagelse:

org.mockito.exceptions.verification.TooLittleActualInvocations: myMock.add (); Ønsket 2 gange: på com.baeldung.mockito.MockitoMockTest .whenUsingMockWithName_thenCorrect (MockitoMockTest.java: ...) men var 1 gang: på com.baeldung.mockito.MockitoMockTest .whenUsingMockWithName_thenCorrect (MockitoMockTest.java: ...

Som vi kan se, er mockens navn inkluderet i undtagelsesmeddelelsen, hvilket vil være nyttigt at finde fejlpunktet i tilfælde af mislykket verifikation.

4. Mocking With Svar

Her vil vi demonstrere brugen af ​​a spotte variant, hvor strategien for mockens svar på interaktion er konfigureret ved oprettelsestidspunktet. Det her spotte metodens signatur i Mockito-dokumentationen ser ud som følger:

offentlig statisk T-mock (Class classToMock, Svar standard Svar)

Lad os starte med definitionen af ​​en implementering af Svar grænseflade:

klasse CustomAnswer implementerer Svar {@Override offentligt boolsk svar (InvocationOnMock påkaldelse) kaster Throwable {return false; }}

Det CustomAnswer klasse ovenfor bruges til generering af en mock:

MyList listMock = mock (MyList.class, ny CustomAnswer ());

Hvis vi ikke indstiller en forventning til en metode, er standardsvaret, som blev konfigureret af CustomAnswer type, kommer i spil. For at bevise det, springer vi over forventningsindstillingen og springer til metodeudførelsen:

boolsk tilføjet = listMock.add (randomAlphabetic (6));

Følgende verifikation og påstand bekræfter, at spotte metode med en Svar argumentet har fungeret som forventet:

verificer (listMock) .add (anyString ()); assertThat (tilføjet, er (falsk));

5. Mocking With MockSettings

Finalen spotte Metoden, der er dækket af denne artikel, er varianten med en parameter for MockSettings type. Denne overbelastede metode bruges til at tilvejebringe en ikke-standard mock.

Der er flere brugerdefinerede indstillinger, der understøttes af metoder til MockSettings interface, såsom at registrere en lytter til metodeopkald på den aktuelle mock med invocationListeners, konfigurerer serialisering med kan serieres, angiver den instans, der skal spioneres med spiedInstance, konfigurerer Mockito til at forsøge at bruge en konstruktør, når man instantierer en mock med useConstructorog nogle andre.

For nemheds skyld vil vi genbruge CustomAnswer klasse introduceret i det foregående afsnit for at oprette en MockSettings implementering, der definerer et standardsvar.

EN MockSettings objektet instantieres ved en fabriksmetode som følger:

MockSettings customSettings = withSettings (). DefaultAnswer (ny CustomAnswer ());

Dette indstillingsobjekt vil blive brugt til oprettelsen af ​​en ny mock:

MyList listMock = mock (MyList.class, customSettings);

Svarende til det foregående afsnit påkalder vi tilføje metode til en MyList forekomst og bekræft, at en spotte metode med en MockSettings argument fungerer som det er meningen med at bruge følgende kodestykke:

boolsk tilføjet = listMock.add (randomAlphabetic (6)); verificer (listMock) .add (anyString ()); assertThat (tilføjet, er (falsk));

6. Konklusion

Denne vejledning har dækket spotte metode til Mockito i detaljer. Implementeringen af ​​disse eksempler og kodestykker kan findes i et GitHub-projekt.