Як знущатися з фінального класу з макетом

У мене є заключний клас, приблизно такий:

public final class RainOnTrees{

   public void startRain(){

        // some code here
   }
}

Я використовую цей клас у якомусь іншому класі, як цей:

public class Seasons{

   RainOnTrees rain = new RainOnTrees();

   public void findSeasonAndRain(){

        rain.startRain();

    }
}

і в моєму тестовому класі JUnit Seasons.javaя хочу знущатися над RainOnTreesкласом. Як я можу це зробити з Mockito?

Знущання з фінальних / статичних класів / методів можливе лише з Mockito v2.

додайте це у свій файл gradle:

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

Це не можливо для Mockito v1, з Mockito FAQ :

Які обмеження Mockito

• Потреби java 1.5+

• Не можна знущатися над заключними класами

...

Mockito 2 тепер підтримує заключні класи та методи!

Але наразі це "інкубаційна" особливість. Для його активації потрібні кілька кроків, описані в розділі Що нового в Mockito 2 :

Знущання над підсумковими заняттями та методами - це інкубаційна , відмінна функція. Для використання мобільності цих типів використовується комбінація інструментальних засобів Java і підкласифікація. Оскільки це працює по-різному від нашого нинішнього механізму, і цей має різні обмеження, і оскільки ми хочемо збирати досвід та відгуки користувачів, цю функцію потрібно було чітко активувати, щоб бути доступною; це можна зробити через механізм розширення mockito, створивши файл, src/test/resources/mockito-extensions/org.mockito.plugins.MockMakerщо містить один рядок:

mock-maker-inline

Після створення цього файлу Mockito автоматично використовуватиме цей новий двигун, і ви зможете зробити:

 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());

У наступних віхах команда запропонує програмний спосіб використання цієї функції. Ми визначимо і надамо підтримку для всіх неможливих сценаріїв. Будьте в курсі, повідомте нас, що ви думаєте про цю функцію!

Ви не можете знущатися з останнього класу з Mockito, як ви не можете зробити це самостійно.

Що я роблю, це створити нефінальний клас, щоб обернути остаточний клас і використовувати як делегат. Прикладом цього є TwitterFactoryклас, і це мій макетний клас:

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();
    }
}

Недоліком є ​​те, що код котла є багато; Перевага полягає в тому, що ви можете додати деякі методи, які можуть бути пов'язані з вашим бізнесом прикладних програм (наприклад, getInstance, який приймає користувача замість accessToken, у наведеному вище випадку).

У вашому випадку я створив би не остаточний RainOnTreesклас, який делегував би остаточному класу. Або, якщо ви зможете зробити це не остаточним, було б краще.

додайте це у свій файл gradle:

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

це конфігурація, щоб змусити макіто працювати з заключними класами

Використовуйте Powermock. Це посилання показує, як це зробити: https://github.com/jayway/powermock/wiki/MockFinal

Просто слідкуйте. Будь ласка, додайте цей рядок до файлу gradle:

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

Я спробував різні версії mockito-core та mockito-all. Жоден з них не працює.

Я думаю, ви це зробили, finalоскільки ви хочете не допустити розширення інших класів RainOnTrees. Як пропонує Ефективна Java (пункт 15), існує інший спосіб тримати клас закритим для розширення, не створюючи його final:

1. Видаліть finalключове слово;

2. Зробіть його конструктор private. Жоден клас не зможе розширити його, оскільки він не зможе викликати superконструктор;

3. Створіть статичний заводський метод для інстанціювання свого класу.

   // 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
       }
   }

Використовуючи цю стратегію, ви зможете використовувати Mockito і тримати свій клас закритим для розширення з невеликим кодовим кодом.

У мене була така ж проблема. Оскільки клас, який я намагався знущатися, був простим класом, я просто створив його примірник і повернув його.

Спробуйте:

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

Це працювало для мене. "SomeMockableType.class" - це батьківський клас того, що ви хочете знущатися чи шпигувати, а someInstanceThatIsNotMockableOrSpyable - це фактичний клас, з якого ви хочете знущатися чи шпигувати.

Докладніше дивіться тут

Іншим вирішенням, яке може застосовуватися в деяких випадках, є створення інтерфейсу, який реалізується цим кінцевим класом, зміна коду, щоб використовувати інтерфейс замість конкретного класу, а потім знущатися над інтерфейсом. Це дозволяє відокремити контракт (інтерфейс) від реалізації (остаточний клас). Звичайно, якщо те, що ви хочете, дійсно прив’язати до випускного класу, це не стосується.

Насправді є один спосіб, який я використовую для шпигунства. Він працював би для вас лише за умови виконання двох передумов:

1. Ви використовуєте якийсь тип DI для введення екземпляру остаточного класу
2. Заключний клас реалізує інтерфейс

Будь ласка, згадайте Пункт 16 з Дієвої Java . Ви можете створити обгортку (не остаточну) та перенаправити всі виклики до екземпляру остаточного класу:

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(); }
}

Тепер ви не тільки можете знущатися над своїм випускним класом, а й шпигувати за ним:

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();

У Mockito 3 і більше я маю ту саму проблему і вирішив її, як за цим посиланням

Насміште підсумкові класи та методи з Mockito, як далі

Перш ніж Mockito можна використовувати для глузування з фінальними класами та методами, його потрібно> налаштувати.

Нам потрібно додати текстовий файл до каталогу src / test / ресурси / mockito-extensions з назвою org.mockito.plugins.MockMaker та додати один рядок тексту:

mock-maker-inline

Mockito перевіряє каталог розширень на наявність файлів конфігурації, коли він завантажується. Цей файл дозволяє глузувати з підсумкових методів та класів.

Заощадження часу для людей, які стикаються з тією ж проблемою (Mockito + Final Class) на Android + Kotlin. Як і в Котліні, класи за замовчуванням є остаточними. Я знайшов рішення в одному з зразків Android Android з компонентом Архітектура. Вибір рішення тут: https://github.com/googlesamples/android-architecture-components/blob/master/GithubBrowserSample

Створіть такі примітки:

/**
 * 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

Змініть файл gradle. Візьмемо приклад звідси: 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'
}

Тепер ви можете коментувати будь-який клас, щоб зробити його відкритим для тестування:

@OpenForTesting
class RepoRepository 

Це можна зробити, якщо ви використовуєте Mockito2, за допомогою нової інкубаційної функції, яка підтримує глузування з фінальних класів та методів.

Основні моменти, які слід зазначити:
1. Створіть простий файл з назвою “org.mockito.plugins.MockMaker” та помістіть його у папку з назвою “mockito-extensions”. Ця папка повинна бути доступною на уроці.
2. Вміст створеного вище файлу повинен бути одним рядком, як зазначено нижче:
макет-виробник-вбудований

Наведені вище кроки необхідні для активації механізму розширення mockito та використання цієї функції відключення.

Зразкові класи такі:

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));

}

}

Сподіваюся, це допомагає.

Повна стаття, представлена ​​тут, насмішкувато-нерозбірлива .

Та сама проблема тут, ми не можемо знущатися з остаточного класу з Mockito. Щоб бути точним, Mockito не може глузувати / шпигувати за наступним:

• заключні заняття
• анонімні заняття
• примітивні типи

Але використання класу обгортки мені здається великою ціною, щоб заплатити, тож отримайте PowerMockito замість цього.

Я думаю, що вам потрібно думати більше в принципі. Замість цього ви остаточного класу використовуєте його інтерфейс та макет інтерфейс.

Для цього:

 public class RainOnTrees{

   fun startRain():Observable<Boolean>{

        // some code here
   }
}

додати

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

і знущаються над інтерфейсом:

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

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

    }

Погляньте, будь ласка, на JMockit . У ньому є велика документація з великою кількістю прикладів. Тут у вас є приклад рішення вашої проблеми (для спрощення я додав конструктор Seasonsдо введення знуреного RainOnTreesекземпляра):

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();
        }

    }
}

Рішення, надані RC та Luigi R. Viggiano разом, можливо, найкраща ідея.

Хоча Mockito не може замислитись над заключними класами, підхід до делегування можливий . У цьому є свої переваги:

1. Ви не змушені змінювати свій клас на незавершений, якщо саме це має намір ваш API в першу чергу (заключні класи мають свої переваги ).
2. Ви перевіряєте можливість прикраси навколо свого API.

У вашому тестовому випадку ви навмисно перенаправляєте виклики до тестуваної системи. Отже, за дизайном ваше оздоблення нічого не робить.

Отже, ви можете також продемонструвати тест, що користувач може лише прикрашати API, а не розширювати його.

Більш суб’єктивна нота: я вважаю за краще зводити рамки до мінімуму, тому JUnit і Mockito зазвичай мені достатньо. Насправді, обмеження цього способу іноді змушує мене також заздалегідь відмовитися.

Якщо ви намагаєтеся запустити блок-тест у тестовій папці, то найкраще рішення буде чудовим. Просто дотримуйтесь його, додаючи розширення.

Але якщо ви хочете запустити його з андроїд- класом, наприклад контекстом або діяльністю, що знаходиться в папці androidtest , відповідь на вас.

Додайте ці залежності для запуску mockito:

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

Як заявили інші, це не вийде з Mockito. Я б запропонував використовувати відображення для встановлення конкретних полів на об'єкті, який використовується тестовим кодом. Якщо ви багато чого робите, ви можете перенести цю функціональність у бібліотеку.

Як убік, якщо ви є одним із класів оцінювання фіналом, припиніть це робити. Я зіткнувся з цим питанням, тому що я працюю з API, де все було позначено остаточним, щоб запобігти моїй законній необхідності розширення (глузування), і я хочу, щоб розробник не припускав, що мені ніколи не потрібно буде розширювати клас.

Для нас це було тому, що ми виключили mockito-inline з koin-тесту. Один модуль gradle насправді потребував цього, і з причини лише вийшов з ладу при складанні релізів (налагоджені збірки в IDE) :-P

Для остаточного класу додайте нижче, щоб знущатися та називати статичне чи нестатичне.

1- додайте це на рівні класу @SuppressStatucInitializationFor (значення = {ім'я класу з пакетом})
2- PowerMockito.mockStatic (classname.class) знущається з класу
3-, а потім використовуватимете заявку, коли повертаєте макетний об'єкт при виклику методу цього класу.

Насолоджуйтесь

Не пробував остаточного, але для приватного використання за допомогою відображення видалити модифікатор працював! перевірили далі, це не працює для фіналу.