Всем привет. Решил вкатиться в тестирование, кажется, я чего-то не

понимаю. Один тест валится с ошибкой "Expected 5, actual 4", второй проходит успешно. Что я делаю не так?!

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

За совет спасибо, это будет отдельный тест. Конкретно первый тест, который падает, проверяет, что при нажатии +/- вызывается колбэк с правильным значением, и оно меняется. Если что, тестируемый виджет — stateless. Мне больше интересно, почему по сути точно такой же второй тест работает

Evgen Fil // hehe
Что-то попахивает 🩼💩🩼, но другого способа не приду...

Эмм а виджет то зачем вручную перестраивать?

stateless

По факту onValueChanged вызывается при нажатии на +1 и -1, в качестве параметра отдаёт новое значение

Evgen Fil // hehe
Что-то попахивает 🩼💩🩼, но другого способа не приду...

Такие тесты называются "хрупкими". Тестировать нужно "черный ящик": на вход подал значение, на выходе получил значение и проверил. У вас же происходит передача не значения, а функции, причем не в виде мок-объекта, а просто и топорно с изменяемым значением изнутри теста. Такой тест, не тест, а часть функционала тестируемого, что плохо. Если бы вы тестировали именно UI и не выходили бы за пределы слоя UI, то такой тест делал бы не нужными эти тесты с коллбеками.

Да, и появление желания передать коллбек, сигнализирует о том, что у вас нет выделения в отдельный слой бизнес логики. Задача UI только получать данные и события тапов/кликов, и отображать данные в виде текста, картинок и т.п. Вся логика должна быть в отдельных классах, которые нужно тестировать отдельно.

Понял принял

А тут не особо понял

Это понятно: "Задача UI только получать данные и события тапов/кликов, и отображать данные в виде текста, картинок и т.п.", надеюсь?

видимо, он о том, что если при написании тестов возникает необходимость переписывать код, значит нарушены принципы SOLID

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

Не через коллбек. Применительно к вашему примеру, создаешь класс class CalcNotifier with ChangeNotifier в нем переменная счетчика и два метода для инкремента и декремента. В этих методах изменяешь переменную счетчика и вызываешь notifyListeners() На странице виджета создаешь экземпляр этого класса _notifier, подписываешься в initState() как слушатель оповещений этого класса _notifier.addListener(setState((){})). В кнопках вызываешь нужные методы из _notifier. А в Text(_notifier.counter). Примерно так.

Чот какой-то бред, имхо

смысл делать через ChangeNotifier если у тебя каллбек это setState? тогда делайте просто через стейтфул виджеты. Если хотите нормальный стейт-менеджмент - отказывайтесь от стейтфул виджета везде, где это возможно. Используйте, например, ListenableBuilder. иначе всё, о чем вы тут пишете, не имеет абсолютно никакого смысла

Бред. Одно другому не мешает. Для микросостояний не зазорно и стейтфул использовать

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

это не микросостояние

Зочем что-то отделять?) На всё по всё есть хуки

Бля понеслось... Что еще придумаешь? Чем еще блеснешь?

Золотом

А почему - помнишь?)

нет, я даже не верен он ли это говорил, или кто то другой

Да многие говорят) всё из за того что билд метод должен быть ... Каким?

Чистой она должна быть) то есть зависит только от стейта и контекста... И при одинаковых аргументах должен одинаковый результат возвращать... Без каких либо сайдээфектов

Ладно, идею с подпиской я осознал, она очень даже неплохая, возьму на заметку