Size: a a a

Android Architecture

2017 January 26

EM

Eugene Matsyuk in Android Architecture
Amir Konovalov
ну 1/10 же
у меня только домашние проекты могли быть только с походом в сеть
а все те приложения, которые я пилил на работе, уж точно не входят в разряд простых и примитивных
источник

AK

Amir Konovalov in Android Architecture
а я бы дома наоборот извращался
источник

I

Ivan in Android Architecture
Eugene Matsyuk
кроме того тесты помогают другому разработчику понять, что здесь можно ожидать и что должно быть
ну вот если мы не будем выходить за рамки этих 9/10 приложений, то какой смысл тестировать метод getItemsFromServer()? Максимум, рх чеин можно посмотреть, разные респонсы подставить. В остальном реально не понимаю. Хуже конечно тесты не сделают, но острой необходимости в них нет. Это, если что, я говорю о юнит тестах. ui тесты это вообще но комментс)
источник

AK

Amir Konovalov in Android Architecture
а на работе как можно больше сервер грузил)
источник

AK

Amir Konovalov in Android Architecture
тесты как защита твоей логики
источник

AK

Amir Konovalov in Android Architecture
чтобы её не похерили
источник

M

Marty in Android Architecture
@eugene_matsyuk

есть сценарий:
Вью дёргает у презентера метод update
Презентер должен что-то сделать и через неопределённое время вызвать у вью метод update(Data d) (а может и не вызвать ничего от ситуации)
Как такое тестируют, к примеру? Поделитесь опытом?
источник

MY

Michael Yeryomenko in Android Architecture
Yuri Shmakov
ИМХО, обязаны. Главная проблема — это как восстановить состояние View. Можно это делать по-разному. Можно сделать ViewModel. Мы решаем эту проблему, исопльзуя Moxy :D Так же в Mosby заложена концепция ViewState, но там нужно самому его восстанавливать. И в ThirtyInch тоже вроде есть восстанавливание стейта
А каково в этом случае время жизни пресентера? Когда он удаляется? Вопрос наверное про moxy, раз вы его используете.
источник

YS

Yuri Shmakov in Android Architecture
Marty
@eugene_matsyuk

есть сценарий:
Вью дёргает у презентера метод update
Презентер должен что-то сделать и через неопределённое время вызвать у вью метод update(Data d) (а может и не вызвать ничего от ситуации)
Как такое тестируют, к примеру? Поделитесь опытом?
Если нужно такое тестировать, то нужно:
1. мокнуть View
2. Мокнуть того, кто будет делать update — мокнутый update должен работать синхронно
3. Проверяете, что когда вызвали метод презетнтера update, на мокнутой View был вызван ожидаемый метод
источник

YS

Yuri Shmakov in Android Architecture
Michael Yeryomenko
А каково в этом случае время жизни пресентера? Когда он удаляется? Вопрос наверное про moxy, раз вы его используете.
В мокси презентер жив, пока не финиширует View, для которой он создавался. Т.е. пока View находится в бэкстэке (в том числе на его вершине), презентер для неё продолжает жить
источник

EM

Eugene Matsyuk in Android Architecture
Ivan
ну вот если мы не будем выходить за рамки этих 9/10 приложений, то какой смысл тестировать метод getItemsFromServer()? Максимум, рх чеин можно посмотреть, разные респонсы подставить. В остальном реально не понимаю. Хуже конечно тесты не сделают, но острой необходимости в них нет. Это, если что, я говорю о юнит тестах. ui тесты это вообще но комментс)
Если приложение такого плана, то, конечно же, не стоит усложнять. Я согласен.
Архитектура должна быть помощником, а не тормозом.
Я скорее придрался к тому, что таких простых приложений не встречал, кроме как в примерах, да свои эксперименты =)
источник

MY

Michael Yeryomenko in Android Architecture
Кто-то пишет или писал на scala под android?
источник

M

Marty in Android Architecture
Yuri Shmakov
Если нужно такое тестировать, то нужно:
1. мокнуть View
2. Мокнуть того, кто будет делать update — мокнутый update должен работать синхронно
3. Проверяете, что когда вызвали метод презетнтера update, на мокнутой View был вызван ожидаемый метод
а смысл тогда
тест покажет что мок с моком работают так как ты их мокнул в тесте
на деле ни вью не презентер ведь не так работают
источник

AG

Artem Gilmudinov in Android Architecture
@kepocnhh тебе надо отловить что был колбек из сервиса и вызван методв вьюхи. Отловить колбек можно через ArgumentCaptor
источник

AG

Artem Gilmudinov in Android Architecture
ловишь инстанс колбека и сам вызываешь метод
источник

YS

Yuri Shmakov in Android Architecture
Marty
а смысл тогда
тест покажет что мок с моком работают так как ты их мокнул в тесте
на деле ни вью не презентер ведь не так работают
Тест покажет, что при определенной отработке update, презентер правильно поменяет view. Так ты будешь уверен, что презентер у тебя написан правильно.
источник

M

Marty in Android Architecture
т.е. у меня должно быть состояние систему в котором (например):
в базе есть 10 записей
после того как у презентера вызвать update во вью волшебным образом должен вызываться метод update(List<Data> l) с 10ю записями
источник

AG

Artem Gilmudinov in Android Architecture
тебе не надо состояние
источник

AG

Artem Gilmudinov in Android Architecture
ты мокаешь сервис который имитирует бд
источник

M

Marty in Android Architecture
Yuri Shmakov
Тест покажет, что при определенной отработке update, презентер правильно поменяет view. Так ты будешь уверен, что презентер у тебя написан правильно.
всё равно не понимаю
это же мок поменяет view а не презентер который я использую на деле
источник