Просто тогда получается, что идеальный тест - это просто прогон вызовов методов с набором входных данных и проверка выходных данных на соответствие ожиданиям

Ну, лык а как иначе?) В этом и смысл теста

Зачем тесту знать, как я результата достиг?

Ок, а тогда какой смысл теста, если он проходит только для предопределенного набора входных значений?

Если поведение тестируемого объекта никак не тестируется на корректность, как я могу знать, что тест корректен и для других входных значений?

Я к тому что может создать Observable.just(text) и как бы смержить их? Паир почему то кажется что костыль, хотя может я и ошибаюсь

concat тебе нужен

А бывают другие тесты? В этом же и смысл, подобрать такие значения, которые проверят корректность кода. Метод, который вычисляет факториал, вы же не проверяет всеми возможными числами?

Для таких атомарных методов - спору нет. Для тестов уровня бизнес-логики надо проверять именно корректность бизнес логики

И не залезаете в подробности реализации метода. Может, он там фабрики фабрик создает, нам это неважно

Ок, а если метод ничего не возвращает, а просто дергает void-методы зависимых классов? Тест, получается, совсем не надо писать?

Для таких атомарных методов - спору нет. Для тестов уровня бизнес-логики надо проверять именно корректность бизнес логики

Проверка презентера сводится к тому, получил ли он данные и сообщил ли вьюхе

Ок, а если метод ничего не возвращает, а просто дергает void-методы зависимых классов? Тест, получается, совсем не надо писать?

Вообще, тест на отдельный метод тоже не очень идея

Он ведь для какого-то кейса вызывается

Хотя, я вот тут разглагольствую, а сам свой первый юнит-тест позавчера написал. Сильно чуваков с энтерпрайза на ютюбе наслушался.

Я сам в прошлом бэкенд писал на джаве)

Кровавый энтерпрайз, системы документооборота с тяжелыми бизнес процессами

Там этого дерьма употребил огромной ложкой

И юнит-тесты писал, и интеграционные)

Я понимаю, о чем ты говоришь, но все же сам для себя пришел к выводу, что под твои категории должны попадать все же больше интеграционные тесты, нежели юнит

Но это, конечно же, тема для долгих дискуссий и я не претендую на исключительную правоту)

Не первый раз вижу синхронизацию через CountDownLatch(1) вместо synchronized(obj). Кто расскажет, есть ли преимущества блокировки защёлкой в плане производительности?

В общем, как я понял из слов бородатых мужиков, юнит-тесты - это тесты одного юнита (ваш К.О). Часто юнит - это один класс, но иногда и пара классов, отвечающих за один кейс. Юнит-тест нацелен на проверку этого юнита без внешнего влияния (читай "моки, стабы" и т.п). Детали реализации юнита тесту должны быть нужны по-минимуму. Сегодня я создаю промежуточный объект прямо в методе, а завтра сооружу дворец фабрик. Если тест завязан на уверенность в гвоздями прибитом флоу, это плохо.

Основной профит от тестов должен быть при изменении кола, рефакторинге, чтобы быть уверенному, что ничего не сломалось.

А если ломаются сами тесты, то это время на ветер.

Кстати, при написании теста под реализацию (без фанатизма, конечно же), очень быстро всплывают все неудачные архитектурные решения

И не только архитектурные

Я сейчас начал покрывать тестами рабочий полулегаси проект, и это все всплывает и без этого)

Так что я не могу согласиться с тем, что тест должен быть черным ящиком. Да, промежуточные всякие значения нам особо не нужно знать. Но без внутряков никак нельзя обойтись, особенно когда кейс более-менее сложный, а-ля "когда пользователь нажал то-то, записать в базу вот это, отстрелить нотификейшн вот сюда, а в том сервисе обновить то-то и вернуть результат"

Гайз, ищем android-разработчика в проект https://vc.ru/n/mrg-foodmate

Гайз, ищем android-разработчика в проект https://vc.ru/n/mrg-foodmate

@mobile_jobs

Так что я не могу согласиться с тем, что тест должен быть черным ящиком. Да, промежуточные всякие значения нам особо не нужно знать. Но без внутряков никак нельзя обойтись, особенно когда кейс более-менее сложный, а-ля "когда пользователь нажал то-то, записать в базу вот это, отстрелить нотификейшн вот сюда, а в том сервисе обновить то-то и вернуть результат"

Не, я ж и не говорю, что надо проверить только "юзер нажал - результат вернулся". Для такого кейса как я вижу текст: "юзер нажал, запись в базу вызвалась, сервис дернулся, нотификейшн как-то показался, результат вернулся"

Эти опорные точки надо проверить, а уж как они достиглись - это неважно

Все, что неважно для кейса (нотификейшн создался ongoing или вообще это тост и подобное) тест не должно интересовать

А если так: UI: 1 тест: нажалась кнопка - вызвался мок юскейс - вернулся отрицательный результат - отобразилась ошибка 2 тест: нажалась кнопка - вызвался мок юскейс - вернулся положительный результат - отобразились данные BL: 3 тест: юскейс с мок репозиторием возвращающим ошибку 4 тест: юскейс с мок репозиторием возвращающим успех ...

лучший юнит-тест — это Настя

+

Но проблема с рефакторингом, при изменении кода считающегося стабильным

А если так: UI: 1 тест: нажалась кнопка - вызвался мок юскейс - вернулся отрицательный результат - отобразилась ошибка 2 тест: нажалась кнопка - вызвался мок юскейс - вернулся положительный результат - отобразились данные BL: 3 тест: юскейс с мок репозиторием возвращающим ошибку 4 тест: юскейс с мок репозиторием возвращающим успех ...

UI юнит-тестам не нужен. Коль у вас юзкейсы (в смысле клин архитектуры?), то тестируйте юзкейсы.

А если проверка, попросил ли презентер показать ошибку, то проблем не вижу

А UI тесты вообще нужны?

А UI тесты вообще нужны?

ну, они существуют

Как бы нет или не очень, но это уже другая тема

Хотя ечпрессо тест раннер удобная штука для верстки, наверное - записал действия, поправил что-то, повторил до просветления.

Всем привет. Кто то юзал https://github.com/Arello-Mobile/Moxy в продакшин ? Поделитесь опытом

просто если у тебя в интерфейсе есть два метода, делающие одно и то ж разными способами - наверное есть смысл проверить внутряки)

просто если у тебя в интерфейсе есть два метода, делающие одно и то ж разными способами - наверное есть смысл проверить внутряки)

Зачем? В одном снекбар показывает строку (форматированную на основе данных), а в другом достает ее из ресурсов и показывет

Ну в идеале да) Но мне кажется в первую очередь нужно проверить сами интерфейсы

А если так: UI: 1 тест: нажалась кнопка - вызвался мок юскейс - вернулся отрицательный результат - отобразилась ошибка 2 тест: нажалась кнопка - вызвался мок юскейс - вернулся положительный результат - отобразились данные BL: 3 тест: юскейс с мок репозиторием возвращающим ошибку 4 тест: юскейс с мок репозиторием возвращающим успех ...

Как бы как я вижу - кнопка нажата - презентер среагировал? - лоадер показался? - данные запрошены? - данные пришли? - данные ок? - лоадер больше не показывается? - новые данные показаны на вьюхе? Как-то так

для меня два разных метода в интерфейсе - это два разных метода. Реализация всегда может сильно поменяться, поэтому надо проверять корректность передачи управления тому или иному методу вьюхи

просто если у тебя в интерфейсе есть два метода, делающие одно и то ж разными способами - наверное есть смысл проверить внутряки)

а это как?

Может я не понял, но вроде как "делающие одно и то же" - это интерфейс, а " разными способами" - его имплементации

для меня два разных метода в интерфейсе - это два разных метода. Реализация всегда может сильно поменяться, поэтому надо проверять корректность передачи управления тому или иному методу вьюхи

Если детали реализации самих двух методов вью поменяются - это не проблема презентера и его теста. А если удалятся - что ж, зачем ты, товарищ, поломал контракт с вьюхой?

Может я не понял, но вроде как "делающие одно и то же" - это интерфейс, а " разными способами" - его имплементации

А ты прочитай выше, там было объяснение

Если детали реализации самих двух методов вью поменяются - это не проблема презентера и его теста. А если удалятся - что ж, зачем ты, товарищ, поломал контракт с вьюхой?

Просто у тебя получается, что реализация твоего теста знает о том, что реализации двух методов интерфейса делают одно и то же. А вот это, на мой взгляд, в корне неправильно

А ты прочитай выше, там было объяснение

а какой конкретно пост?)

А как по мне, то 2 перегруженные методы, делающие абсолютно разные вещи - намного печальнее. И если мне тест на это покажет, я скажу ему спасибо)

Не первый раз вижу синхронизацию через CountDownLatch(1) вместо synchronized(obj). Кто расскажет, есть ли преимущества блокировки защёлкой в плане производительности?

у них немного разное назначение. synchronized позволяет просто сделать семафор и выполнить код потокобезопасно. c CountDownLatch можно сделать всякие другие вещи. Например можно ждать окончания выполнения какого-то кода в другом потоке(ках) да еще и с таймаутом

у них немного разное назначение. synchronized позволяет просто сделать семафор и выполнить код потокобезопасно. c CountDownLatch можно сделать всякие другие вещи. Например можно ждать окончания выполнения какого-то кода в другом потоке(ках) да еще и с таймаутом

Ну, что можно сделать с защелкой, я представляю, просто когда начальное значение счетчика выставлено в единицу, то там же тот же синхронайзд получается

Ну, что можно сделать с защелкой, я представляю, просто когда начальное значение счетчика выставлено в единицу, то там же тот же синхронайзд получается

если в другом потоке ничего не происходит, то синхронайзд код сразу будет выполнен. а с латчем будет ждать пока кто-то где-то счетчик обнулит

если в другом потоке ничего не происходит, то синхронайзд код сразу будет выполнен. а с латчем будет ждать пока кто-то где-то счетчик обнулит

А, точно, вспомнил - давно ими не пользовался просто

Впрочем, мы точно так же можем wait/notifyAll использовать

А, точно, вспомнил - давно ими не пользовался просто

да, они для разного

Впрочем, мы точно так же можем wait/notifyAll использовать

ну можем, но апи разный будет

у них есть область пересечения сфер применения, но в общем разное назначение

ну можем, но апи разный будет

А по производительности они одинаковы?

ERROR: S client not available

я бы, конечно, изучил как читать байткод и какие операции сколько выполняются, но ради одной этой задачи жирновато

А по производительности они одинаковы?

вот этого не знаю. не было кейза чтобы стоило об этом думать вообще

Впрочем, мы точно так же можем wait/notifyAll использовать

кстати, почему не рекомендуется так использовать wait/notifyAll, вместо этого лучше библиотеку concurent? легко ошибиться?

Вероятнее всего, потому что на классах из библиотеки намного проще построить значительно более читабельный и внятный код)

А то иногда понатыкают wait и notify, а потом разбираешься и пытаешься понять, а как вообще предполагалось, что это должно работать? =)

есть более быстрые и удобные аналоги синхронизации, чем wait/notify

это если легаси - то да

есть более быстрые и удобные аналоги синхронизации, чем wait/notify

вы про библиотеки? а засчет чего быстрее, удобные библиотеки не на этих примитивах строятся?

Вероятнее всего, потому что на классах из библиотеки намного проще построить значительно более читабельный и внятный код)

ок, это аргумент!)

нет не библиотеки, из java.util.concurrent пакета

Это уже детали)

нет не библиотеки, из java.util.concurrent пакета

xxxLock?

ага

Так-то пакет concurrency входит в JCL

окей, а есть сравнения производительности wait/notify и synchronized с java.util.concurrent.locks?

не знаю, я не искал, но из описания как работает ReentrantLock например, делаю вывод что оно не хило оптимизируется в процессе выполнения

наврядли wait/notify это могут

может я не прав)не буду утверждать 100%)

Какие проблемы в андроид разработке, в приложении RxJava помогает решить?

опять же правда оговорка, все зависит от задачи, сколько потоков и как часто борятся на ресурсы

не знаю, я не искал, но из описания как работает ReentrantLock например, делаю вывод что оно не хило оптимизируется в процессе выполнения

Вероятно, так и есть) Не удивлюсь если там есть какие-то нативные методы или активно юзается unsafe)

Какие проблемы в андроид разработке, в приложении RxJava помогает решить?

Имхо, упрощает управление потоками, упрощает последовательную обработку данных (chaining операций и вот это вот все), принуждает к иммутабельности

вообще лучше юзать CAS если мало поточное приложение

вообще лучше юзать CAS если мало поточное приложение

неблокирующие программы писать крайне сложно, плюс даже там блокировки-то вполне себе присутствуют

как бы мы не хотели, но там вроде как от спинлока не избавиться же

как бы мы не хотели, но там вроде как от спинлока не избавиться же

Ты залочен, а твой сосед зато выполняет полезную работу

Имхо, упрощает управление потоками, упрощает последовательную обработку данных (chaining операций и вот это вот все), принуждает к иммутабельности

Запрос на сервер, обработка данных, запрос в базу, синхронизация, отмена операций, всякие нотификации в ui для этого мне нужен Rx?

Вполне)

Запрос на сервер, обработка данных, запрос в базу, синхронизация, отмена операций, всякие нотификации в ui для этого мне нужен Rx?

На нём очень много можно сделать. Нужен он тебе или нет - решать только тебе

Rx — топчик

Если не было опыта - советую чисто для себя наваять песочницу и посмотреть. Желательно, чтобы были запросы к апишке, кэширование в базу и т.д. и т.п.