Jak kpić z ostatniej klasy za pomocą mockito

Mam ostatnią klasę, coś takiego:

public final class RainOnTrees{

   public void startRain(){

        // some code here
   }
}

Korzystam z tej klasy w innej klasie, takiej jak ta:

public class Seasons{

   RainOnTrees rain = new RainOnTrees();

   public void findSeasonAndRain(){

        rain.startRain();

    }
}

i w mojej klasie testowej JUnit, Seasons.javabo chcę z niej kpić RainOnTrees. Jak mogę to zrobić za pomocą Mockito?

Wyśmiewanie klas / metod statycznych / końcowych jest możliwe tylko w Mockito v2.

dodaj to do pliku oceny:

testImplementation 'org.mockito:mockito-inline:2.13.0'

Nie jest to możliwe w Mockito v1 z FAQ Mockito :

Jakie są ograniczenia Mockito

• Potrzebuje java 1.5+

• Nie można kpić z ostatnich klas

...

Mockito 2 obsługuje teraz końcowe klasy i metody!

Ale na razie jest to funkcja „inkubująca”. Aktywacja wymaga kilku kroków opisanych w części Co nowego w Mockito 2 :

Kpiny z końcowych klas i metod to inkubująca opcja akceptacji. Wykorzystuje kombinację instrumentacji agenta Java i podklasowania, aby umożliwić wyśmiewanie tych typów. Ponieważ działa to inaczej niż nasz obecny mechanizm, a ten ma inne ograniczenia i ponieważ chcemy zebrać doświadczenie i opinie użytkowników, ta funkcja musiała zostać wyraźnie aktywowana, aby była dostępna; można to zrobić za pomocą mechanizmu rozszerzenia mockito, tworząc plik src/test/resources/mockito-extensions/org.mockito.plugins.MockMakerzawierający jedną linię:

mock-maker-inline

Po utworzeniu tego pliku Mockito automatycznie użyje tego nowego silnika i można:

 final class FinalClass {
   final String finalMethod() { return "something"; }
 }

 FinalClass concrete = new FinalClass(); 

 FinalClass mock = mock(FinalClass.class);
 given(mock.finalMethod()).willReturn("not anymore");

 assertThat(mock.finalMethod()).isNotEqualTo(concrete.finalMethod());

W kolejnych etapach zespół przyniesie programowy sposób korzystania z tej funkcji. Zidentyfikujemy i zapewnimy wsparcie dla wszystkich niemożliwych do wyrejestrowania scenariuszy. Bądź na bieżąco i daj nam znać, co myślisz o tej funkcji!

Nie możesz kpić z ostatniej klasy za pomocą Mockito, ponieważ nie możesz tego zrobić sam.

To, co robię, to stworzyć nie-końcową klasę, aby owinąć klasę końcową i użyć jako delegata. Przykładem tego jest TwitterFactoryklasa, a to moja próbna klasa:

public class TwitterFactory {

    private final twitter4j.TwitterFactory factory;

    public TwitterFactory() {
        factory = new twitter4j.TwitterFactory();
    }

    public Twitter getInstance(User user) {
        return factory.getInstance(accessToken(user));
    }

    private AccessToken accessToken(User user) {
        return new AccessToken(user.getAccessToken(), user.getAccessTokenSecret());
    }

    public Twitter getInstance() {
        return factory.getInstance();
    }
}

Wadą jest to, że istnieje wiele kodów typu „Boiler Plate”; zaletą jest to, że możesz dodać niektóre metody, które mogą odnosić się do Twojej działalności związanej z aplikacjami (np. getInstance, która bierze użytkownika zamiast accessToken, w powyższym przypadku).

W twoim przypadku stworzyłbym nie-końcową RainOnTreesklasę, która delegowałaby się do klasy ostatecznej. Lub, jeśli możesz sprawić, że będzie niefinałowy, byłoby lepiej.

dodaj to do pliku oceny:

testImplementation 'org.mockito:mockito-inline:2.13.0'

jest to konfiguracja umożliwiająca mockito pracę z klasami końcowymi

Użyj Powermock. Ten link pokazuje, jak to zrobić: https://github.com/jayway/powermock/wiki/MockFinal

Tylko po to. Dodaj ten wiersz do pliku oceny:

testCompile group: 'org.mockito', name: 'mockito-inline', version: '2.8.9'

Próbowałem różnych wersji mockito-core i mockito-all. Żadne z nich nie działa.

Myślę, że udało ci się, finalponieważ chcesz zapobiec rozszerzaniu innych klas RainOnTrees. Jak sugeruje Effective Java (punkt 15), istnieje inny sposób na utrzymanie klasy blisko do rozszerzenia bez robienia tego final:

1. Usuń finalsłowo kluczowe;

2. Zrób jego konstruktora private. Żadna klasa nie będzie w stanie go rozszerzyć, ponieważ nie będzie w stanie wywołać superkonstruktora;

3. Utwórz statyczną metodę fabryczną, aby utworzyć instancję klasy.

   // No more final keyword here.
   public class RainOnTrees {
   
       public static RainOnTrees newInstance() {
           return new RainOnTrees();
       }
   
   
       private RainOnTrees() {
           // Private constructor.
       }
   
       public void startRain() {
   
           // some code here
       }
   }

Korzystając z tej strategii, będziesz mógł korzystać z Mockito i utrzymywać klasę zamkniętą, aby móc ją rozszerzać za pomocą niewielkiego kodu.

Miałem ten sam problem. Ponieważ klasa, którą próbowałem kpić, była prostą klasą, po prostu stworzyłem jej instancję i zwróciłem ją.

Wypróbuj to:

Mockito.mock(SomeMockableType.class,AdditionalAnswers.delegatesTo(someInstanceThatIsNotMockableOrSpyable));

To zadziałało dla mnie. „SomeMockableType.class” to klasa nadrzędna tego, co chcesz wyśmiewać lub szpiegować, a someInstanceThatIsNotMockableOrSpyable to klasa, którą chcesz wyśmiewać lub szpiegować.

Aby uzyskać więcej informacji, zobacz tutaj

Innym obejściem, które może mieć zastosowanie w niektórych przypadkach, jest utworzenie interfejsu, który jest implementowany przez tę ostatnią klasę, zmiana kodu w celu użycia interfejsu zamiast konkretnej klasy, a następnie wyśmiewanie interfejsu. Pozwala to oddzielić umowę (interfejs) od implementacji (klasa końcowa). Oczywiście, jeśli naprawdę chcesz powiązać się z klasą końcową, nie będzie to miało zastosowania.

Właściwie jest jeden sposób, którego używam do szpiegowania. Przydałoby się to tylko wtedy, gdy spełnione są dwa warunki wstępne:

1. Używasz jakiegoś DI do wstrzykiwania instancji klasy końcowej
2. Klasa końcowa implementuje interfejs

Proszę przywołać punkt 16 z Effective Java . Możesz utworzyć opakowanie (nie ostateczne) i przekazać wszystkie wywołania do instancji klasy końcowej:

public final class RainOnTrees implement IRainOnTrees {
    @Override public void startRain() { // some code here }
}

public class RainOnTreesWrapper implement IRainOnTrees {
    private IRainOnTrees delegate;
    public RainOnTreesWrapper(IRainOnTrees delegate) {this.delegate = delegate;}
    @Override public void startRain() { delegate.startRain(); }
}

Teraz możesz nie tylko kpić z ostatniej klasy, ale także szpiegować ją:

public class Seasons{
    RainOnTrees rain;
    public Seasons(IRainOnTrees rain) { this.rain = rain; };
    public void findSeasonAndRain(){
        rain.startRain();
   }
}

IRainOnTrees rain = spy(new RainOnTreesWrapper(new RainOnTrees()) // or mock(IRainOnTrees.class)
doNothing().when(rain).startRain();
new Seasons(rain).findSeasonAndRain();

W Mockito 3 i więcej mam ten sam problem i naprawiłem go z tego linku

Wyśmiewaj końcowe klasy i metody za pomocą Mockito w następujący sposób

Zanim Mockito będzie można wykorzystać do kpienia z końcowych klas i metod, należy go> skonfigurować.

Musimy dodać plik tekstowy do katalogu projektu src / test / resources / mockito-extensions o nazwie org.mockito.plugins.MockMaker i dodać jeden wiersz tekstu:

mock-maker-inline

Mockito sprawdza, czy w katalogu rozszerzeń nie ma plików konfiguracyjnych podczas ładowania. Ten plik umożliwia wyśmiewanie końcowych metod i klas.

Oszczędność czasu dla osób, które borykają się z tym samym problemem (Mockito + klasa ostateczna) na Androidzie + Kotlin. Podobnie jak w przypadku Kotlin klasy są domyślnie ostateczne. Znalazłem rozwiązanie w jednym z przykładów Google Android z komponentem Architecture. Rozwiązanie wybrane tutaj: https://github.com/googlesamples/android-architecture-components/blob/master/GithubBrowserSample

Utwórz następujące adnotacje:

/**
 * This annotation allows us to open some classes for mocking purposes while they are final in
 * release builds.
 */
@Target(AnnotationTarget.ANNOTATION_CLASS)
annotation class OpenClass

/**
 * Annotate a class with [OpenForTesting] if you want it to be extendable in debug builds.
 */
@OpenClass
@Target(AnnotationTarget.CLASS)
annotation class OpenForTesting

Zmodyfikuj plik oceny. Weź przykład z tego miejsca: https://github.com/googlesamples/android-architecture-components/blob/master/GithubBrowserSample/app/build.gradle

apply plugin: 'kotlin-allopen'

allOpen {
    // allows mocking for classes w/o directly opening them for release builds
    annotation 'com.android.example.github.testing.OpenClass'
}

Teraz możesz dodać adnotację do dowolnej klasy, aby była otwarta do testowania:

@OpenForTesting
class RepoRepository 

Można to zrobić, jeśli używasz Mockito2, z nową funkcją inkubacji, która obsługuje wyśmiewanie końcowych klas i metod.

Najważniejsze kwestie do zapamiętania:
1. Utwórz prosty plik o nazwie „org.mockito.plugins.MockMaker” i umieść go w folderze o nazwie „rozszerzenia mockito”. Ten folder powinien zostać udostępniony w ścieżce klasy.
2. Treść pliku utworzonego powyżej powinna być pojedynczą linią, jak podano poniżej:
mock-maker-inline

Powyższe dwa kroki są wymagane w celu aktywacji mechanizmu rozszerzenia mockito i skorzystania z tej opcji opt-in.

Przykładowe klasy są następujące:

FinalClass.java

public final class FinalClass {

public final String hello(){
    System.out.println("Final class says Hello!!!");
    return "0";
}

}

Foo.java

public class Foo {

public String executeFinal(FinalClass finalClass){
    return finalClass.hello();
}

}

FooTest.java

public class FooTest {

@Test
public void testFinalClass(){
    // Instantiate the class under test.
    Foo foo = new Foo();

    // Instantiate the external dependency
    FinalClass realFinalClass = new FinalClass();

    // Create mock object for the final class. 
    FinalClass mockedFinalClass = mock(FinalClass.class);

    // Provide stub for mocked object.
    when(mockedFinalClass.hello()).thenReturn("1");

    // assert
    assertEquals("0", foo.executeFinal(realFinalClass));
    assertEquals("1", foo.executeFinal(mockedFinalClass));

}

}

Mam nadzieję, że to pomoże.

Pełny artykuł obecny tutaj drwiący z niemożliwego do wyśmiewania .

Tak, ten sam problem tutaj, nie możemy kpić z ostatniej klasy z Mockito. Aby być dokładnym, Mockito nie może kpić / szpiegować następujących elementów:

• zajęcia końcowe
• anonimowe zajęcia
• typy prymitywne

Ale korzystanie z klasy otoki wydaje mi się dużą ceną do zapłaty, więc zamiast tego kup PowerMockito.

Myślę, że zasadniczo musisz więcej myśleć. Zamiast tego ostatnia klasa używa jego interfejsu i fałszywego interfejsu.

Dla tego:

 public class RainOnTrees{

   fun startRain():Observable<Boolean>{

        // some code here
   }
}

Dodaj

interface iRainOnTrees{
  public void startRain():Observable<Boolean>
}

i kpię z interfejsu:

 @Before
    fun setUp() {
        rainService= Mockito.mock(iRainOnTrees::class.java)

        `when`(rainService.startRain()).thenReturn(
            just(true).delay(3, TimeUnit.SECONDS)
        )

    }

Proszę spojrzeć na JMockit . Ma obszerną dokumentację z wieloma przykładami. Oto przykładowe rozwiązanie problemu (dla uproszczenia dodałem konstruktora Seasonsdo wstrzykiwania fałszywej RainOnTreesinstancji):

package jmockitexample;

import mockit.Mocked;
import mockit.Verifications;
import mockit.integration.junit4.JMockit;
import org.junit.Test;
import org.junit.runner.RunWith;

@RunWith(JMockit.class)
public class SeasonsTest {

    @Test
    public void shouldStartRain(@Mocked final RainOnTrees rain) {
        Seasons seasons = new Seasons(rain);

        seasons.findSeasonAndRain();

        new Verifications() {{
            rain.startRain();
        }};
    }

    public final class RainOnTrees {
        public void startRain() {
            // some code here
        }

    }

    public class Seasons {

        private final RainOnTrees rain;

        public Seasons(RainOnTrees rain) {
            this.rain = rain;
        }

        public void findSeasonAndRain() {
            rain.startRain();
        }

    }
}

Rozwiązania dostarczone wspólnie przez RC i Luigi R. Viggiano są prawdopodobnie najlepszym pomysłem.

Chociaż Mockito z założenia nie może kpić z klas końcowych, podejście do delegowania jest możliwe . Ma to swoje zalety:

1. Nie jesteś zmuszony zmienić swojej klasy na nie-końcową, jeśli takie jest zamierzenie twojego API (klasy końcowe mają swoje zalety ).
2. Testujesz możliwość dekoracji wokół swojego interfejsu API.

W przypadku testowym celowo przekazujesz połączenia do testowanego systemu. Dlatego z założenia twoja dekoracja nic nie robi.

Dlatego test może również wykazać, że użytkownik może jedynie udekorować interfejs API zamiast go rozszerzać.

Mówiąc bardziej subiektywnie: wolę ograniczać frameworki do minimum, dlatego JUnit i Mockito są zwykle dla mnie wystarczające. W rzeczywistości ograniczenie tego sposobu czasami zmusza mnie również do refaktoryzacji na dobre.

Jeśli próbujesz uruchomić test jednostkowy w folderze testowym , najlepsze rozwiązanie jest w porządku. Wystarczy go dodać, dodając rozszerzenie.

Ale jeśli chcesz uruchomić go z klasą związaną z Androidem , taką jak kontekst lub aktywność, która znajduje się w folderze androidtest , odpowiedź jest dla Ciebie.

Dodaj te zależności, aby pomyślnie uruchomić mockito:

testImplementation 'org.mockito: mockito-core: 2.24.5'
testImplementation "org.mockito: mockito-inline: 2.24.5"

Jak powiedzieli inni, nie będzie to działać po wyjęciu z pudełka z Mockito. Sugerowałbym użycie refleksji do ustawienia określonych pól na obiekcie używanym przez testowany kod. Jeśli często to robisz, możesz zawinąć tę funkcję w bibliotekę.

Nawiasem mówiąc, jeśli jesteś jedynym, który zalicza zajęcia do klasy, przestań to robić. Natknąłem się na to pytanie, ponieważ pracuję z interfejsem API, w którym wszystko oznaczono jako ostateczne, aby zapobiec mojej uzasadnionej potrzebie rozszerzenia (kpiny) i żałuję, że programista nie założył, że nigdy nie będę musiał rozszerzać klasy.

Dla nas było tak dlatego, że wykluczyliśmy mockito-inline z testu koin. Jeden moduł stopniowy faktycznie tego potrzebował i z powodu nie powiódł się tylko w kompilacjach wersji (kompilacje debugowania w IDE działały) :-P

Aby dodać klasę końcową, dodaj poniżej, aby udawać i nazwij statyczną lub niestatyczną.

1- dodaj to na poziomie klasy @SuppressStatucInitializationFor (wartość = {nazwa klasy z pakietem))
2- PowerMockito.mockStatic (classname.class) wyśmieje klasę
3, a następnie użyje instrukcji when, aby zwrócić obiekt próbny podczas wywoływania metody tej klasy.

Cieszyć się

Nie próbowałem ostatecznego, ale dla prywatnego, używając odbicia usuń modyfikator działał! sprawdziłem dalej, to nie działa na ostateczne.