Почему тестируются экземпляры базового класса с зависимостями Android? - PullRequest
Новая
       7

Почему тестируются экземпляры базового класса с зависимостями Android?

0 голосов
/ 03 июля 2018

Я пытаюсь понять, почему конкретные экземпляры абстрактного класса с зависимостями android от него являются модульно тестируемыми. Рассмотрим следующий класс: 

import android.arch.lifecycle.Lifecycle;
import android.arch.lifecycle.LifecycleObserver;
import android.arch.lifecycle.LiveData;
import android.arch.lifecycle.Observer;
import android.arch.lifecycle.OnLifecycleEvent;

public abstract class BaseFoo implements LifecycleObserver {

    @OnLifecycleEvent(Lifecycle.Event.ON_RESUME)
    public void onResume() {
        ...
    }

    @OnLifecycleEvent(Lifecycle.Event.ON_CREATE)
    public void onCreate() {
        ...
    }

    @OnLifecycleEvent(Lifecycle.Event.ON_DESTROY)
    public void onDestroy() {
        ...
    }

    @OnLifecycleEvent(Lifecycle.Event.ON_PAUSE)
    public void onPause() {
        ...
    }

    ...
}

И 

public class ConcreteFoo extends BaseFoo {

    public void bar() {
        ...
    }
}

Тесты основаны так: 

import android.arch.lifecycle.Lifecycle;

public abstract class BaseTest {

    @Mock protected Lifecycle lifecycle;

    ...
}

Учитывая зависимости Android от каждого класса, почему может что-то вроде: 

@RunWith(MockitoJUnitRunner.class)
public class FooTest extends BaseTest {

    @Test
    public void testSomething() {
        ...
    }
}

быть тестируемым на единицу для ConcreteFoo? Только потому, что lifecycle высмеивают в BaseTest? Если так, то как это может быть действительно протестировано в соответствии с реальными системными обратными вызовами устройств? Как избежать ошибки в таких тестах? Есть ли в Mockito что-то особенное, что позволяет это, чего не может быть у других фреймворков?

1 Ответ

0 голосов
/ 05 июля 2018

«Классы с зависимостями Android не поддаются тестированию», по-видимому, имеют довольно специфическое значение.

Возьмите классическое задание или фрагмент. Часто существует большая зависимость от TextView, LayoutManager и т. Д. Практически невозможно заглушить поведение для каждой отдельной зависимости, чтобы выполнить какой-либо разумный модульный тест. Обратите внимание, что зависимости TextView и т. Д. Являются классами android.*, которые включены в среду выполнения устройства под управлением Android (т. Е. Вашего телефона).

Плохо спроектированные классы Presenter и ViewModel также могут иметь эту проблему. Например, если Presenter или ViewModel получают зависимость от контекста, будет трудно поместить их в тестовую систему, так как класс контекста android.* трудно подделать.

Однако эта директива не обязательно применяется к классам android.arch.*. Они не включены в среду выполнения Android на телефоне и разработаны таким образом, чтобы облегчить тестирование. Таким образом, в приведенном вами примере, кажется, нет ошибки при включении их в класс, предназначенный для модульного тестирования.

...