Size: a a a

Android Architecture

2017 February 05

ZZ

Zahar Zolotarev in Android Architecture
Добрый день, всем) возник вопрос, как тестироввать View (из MVP)  если это фрагмент?
Предполагаю что через Robolectric и startVisibleFragment() ? но как быть с зависимостями Dagger2?
источник

SD

Sergey D in Android Architecture
А что там тестировать ? Нажатие на кнопку? Еспресо
источник

SD

Sergey D in Android Architecture
А если мвп то там болше ничего нет все в презентере
источник

ZZ

Zahar Zolotarev in Android Architecture
что у вьх состояние правильное (скрыты\нескрыты, enabled\disabled), что текст в нужны TextVIew передался, что диалог показался и т.д.
источник

SD

Sergey D in Android Architecture
Так это еспресо все делает
источник

ZZ

Zahar Zolotarev in Android Architecture
вопросы был не "Зачем" а "как"
источник

ZZ

Zahar Zolotarev in Android Architecture
еспрессо покрытие не считает) и девайса требует)
источник

SD

Sergey D in Android Architecture
Так а в чем проблема девайс?
источник

SD

Sergey D in Android Architecture
И что такое покрытие?
источник

ZZ

Zahar Zolotarev in Android Architecture
сейчас у меня поля который inject без модификатора видимости,
и примерно вот так написан тест:

@Mock DrawerMenuPresenter presenter;
@Mock ImageLoader imageLoader;
@Mock protected IToolbar toolbar;
@Mock protected UIResolver uiRes;
@Mock protected ThrowableResolver throwable;
@Mock protected NavigationResolver navigationResolver;
private DrawerMenuScreenFragment fragment;
private DrawerMenuView view;

@Before
public void init() {
 view = fragment = Mockito.spy(DrawerMenuScreenFragment.open());
 doNothing().when(fragment)
   .daggerInject();
 doReturn(presenter).when(fragment)
   .getPresenter();
 fragment.imageLoader = imageLoader;
 fragment.uiResolver = uiRes;
 fragment.throwableResolver = throwable;
 fragment.navigationResolver = navigationResolver;
 fragment.toolbar = toolbar;
}

я думаю что это не труЪ поэтому спрашиваю как это сделать через dagger2)
источник

ZZ

Zahar Zolotarev in Android Architecture
Sergey D
И что такое покрытие?
показывать какой код покрыт тестами, а какой нет)
источник

МИ

Михаил Иванов in Android Architecture
Zahar Zolotarev
еспрессо покрытие не считает) и девайса требует)
Вместо девайса эмулятор, покрытие тоже можно посчитать https://codelabs.developers.google.com/codelabs/android-testing/index.html?index=../../index#10
источник

ZZ

Zahar Zolotarev in Android Architecture
вопрос не про eспрессо) К тому же, это не UnitTest)
а покрытие только для UnitTes считается.
разве нет?
источник

ZZ

Zahar Zolotarev in Android Architecture
тем не менее, сейчас мой вопрос по даггер, а не eспрессо
источник

SD

Sergey D in Android Architecture
Я хз. Есть анотация визиблфортест может поможет чемто
источник

DB

Dmitry Berdnikov in Android Architecture
@eugene_matsyuk а вы выделяете базовый абстрактный класс для репозитория, чтобы базовые переменные для работы с сетью, бд туда вынести например? чтобы в каждом репозитории не прописывать их? и храните ли app context в нем? если например надо в преференсы залесть? или обертку пишите и через него общаетесь в репозитории?
источник

А

Андрей in Android Architecture
Alexander Blinov
У меня в  котлине это реализовано через object (сущность в котлине синглтон)
У себя тоже так делаем. В результате каждый занимается своей роботой и класс апликейшена не разростается.
источник

А

Андрей in Android Architecture
Zahar Zolotarev
вопрос не про eспрессо) К тому же, это не UnitTest)
а покрытие только для UnitTes считается.
разве нет?
нет. просто джакоко для юнит тестов и девайс тестов в разных местах отчеты создает. на просторах интернета встречал статьи, как написать грейдл таск чтоб эти отчеты мерджились в один.
источник

EM

Eugene Matsyuk in Android Architecture
Dmitry Berdnikov
@eugene_matsyuk а вы выделяете базовый абстрактный класс для репозитория, чтобы базовые переменные для работы с сетью, бд туда вынести например? чтобы в каждом репозитории не прописывать их? и храните ли app context в нем? если например надо в преференсы залесть? или обертку пишите и через него общаетесь в репозитории?
По мне абстрактный класс Репозитория не нужен. А в чем проблема с классами по работе с БД, сетью и т.д.
Возьмем сеть и библиотеку Retrofit. Вы же все равно будете использовать конкретные интерфейсы. А всякие RestAdapter и прочее остаются в соответствующем даггеровском модуле.
Необходимые зависимости Даггером пробрасываете, и все отлично.
Вообщем юзайте Даггер, и все будет хорошо =)
Context можно пробросить. Для тех же Shared Preferences. С ними да, лучше работать через специальную обертку или адаптер. Так у вас будет все под контролем с shared preferences в одном классе. А то напосоздают имплементации SP, а это все perfomance - не хорошо.
источник

DB

Dmitry Berdnikov in Android Architecture
Eugene Matsyuk
По мне абстрактный класс Репозитория не нужен. А в чем проблема с классами по работе с БД, сетью и т.д.
Возьмем сеть и библиотеку Retrofit. Вы же все равно будете использовать конкретные интерфейсы. А всякие RestAdapter и прочее остаются в соответствующем даггеровском модуле.
Необходимые зависимости Даггером пробрасываете, и все отлично.
Вообщем юзайте Даггер, и все будет хорошо =)
Context можно пробросить. Для тех же Shared Preferences. С ними да, лучше работать через специальную обертку или адаптер. Так у вас будет все под контролем с shared preferences в одном классе. А то напосоздают имплементации SP, а это все perfomance - не хорошо.
Ну тот же ретрофит, я обычно этот интерфейс который описывает апи и держу в репозитории, я так понял вы предложили еще одну обертку над сетью?
источник