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

На морде - через рид

На морде - через рид

Значит через бд

Знаю, что геттеры дергаются если их прям группами разметить.

Ну а без групп должен дёргать все геттеры вроде

Понял, проверю, спасибо.

Значит через бд

Так это же юнит, или вообще нет бд - может приложение в памяти

Ага, обжект нормалацзер

Так это же юнит, или вообще нет бд - может приложение в памяти

Тогда будет какой-то объект с публичным методом для просмотра

Тогда будет какой-то объект с публичным методом для просмотра

Зачем? Есть класс, есть состояние за которым он следит и меняет через операции сложные. Нет сеттеров и геттеров.

Зачем? Есть класс, есть состояние за которым он следит и меняет через операции сложные. Нет сеттеров и геттеров.

За тем, чтобы показать цифру человеку

За тем, чтобы показать цифру человеку

А может и не надо)

Тогда и тестировать не надо изменение цифры. Тестируц через отлов исключений. Если тебе не нужна информация о цифре

За тем, чтобы показать цифру человеку

Ну например: есть животное у него есть показатель голода. Животное умеет бегать, ходить и кушать. Бегать и ходить по разному уменьшает сытость, а кушать - пополняет. Если сытость = 0, корова дохнет. Как видишь снаружи нам голод не нужен

Ну например: есть животное у него есть показатель голода. Животное умеет бегать, ходить и кушать. Бегать и ходить по разному уменьшает сытость, а кушать - пополняет. Если сытость = 0, корова дохнет. Как видишь снаружи нам голод не нужен

Индикатор голода будет? ) Или счётчик до смерти

Индикатор голода будет? ) Или счётчик до смерти

Так это внутри коровы

Нам по логике не нужен снаружи этот индикатор

Ну, как юзер поймет что корову пора покормить?

Так это внутри коровы

Событие вылетит

Мы же говорим про корову как программный объект? 😄

Ну, как юзер поймет что корову пора покормить?

А как фермер знает что надо кормить - а никак, он предполагает

Событие вылетит

Для кого?

Корова сама ходит и кушает

Для кого?

Для того, кто корову танцует

Для того, кто корову танцует

Корова сама себя танцует

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

Корова сама себя танцует

Тогда никому не важно, живая она или нет

и тестировать некому и незачем

Тогда никому не важно, живая она или нет

Это уже придумано вами. Есть луг, есть коровы там травка растёт коровы бегают, а когда голодны - пытаются искать траву и есть. А пользователь добравляет убирает коров и смотрит как они живут или дохнут

Короче придумать можно что угодно

Чтобы заппогать действия на голод, надо будет чтобы кто-то о нем знал. Значит индикатор голода публичный. Не?

Тестировать становится не проблема

Это уже придумано вами. Есть луг, есть коровы там травка растёт коровы бегают, а когда голодны - пытаются искать траву и есть. А пользователь добравляет убирает коров и смотрит как они живут или дохнут

Пользователь на процесс выпаса никак не влияет. Просто смотрит. Зачем здесь что-то тестировать?

Опять таки, можно протестировать совместно кормежку смерть и бег совместно - но тест трогает несколько методов

Опять таки, можно протестировать совместно кормежку смерть и бег совместно - но тест трогает несколько методов

Ну и правильно

Опять таки, можно протестировать совместно кормежку смерть и бег совместно - но тест трогает несколько методов

Покормили меньше чем побегали – получили событие, что корова кончилась. Это и будет тест.

Пользователь на процесс выпаса никак не влияет. Просто смотрит. Зачем здесь что-то тестировать?

Тестировать что корова может сдохнуть, что корова тратит сытость от бега

Покормили меньше чем побегали – получили событие, что корова кончилась. Это и будет тест.

Только это тестирование целого кейса который затрагивает несколько методов

И в результате не понятно что именно сломано

Да, сломан кейс - это тест и норм, но тест всего сценария, а не 1 операции

Только это тестирование целого кейса который затрагивает несколько методов

Так юнит-тесты и тестируют кейсы. Всё верно.

Чтобы заппогать действия на голод, надо будет чтобы кто-то о нем знал. Значит индикатор голода публичный. Не?

Там только один сайд эффект - корова сдохла, который можно получить предварительно покормив а потом побегав. Т.е. Участвуют 2 операции и 1 эффект. Что в итоге мы из этого тестировали?

Так юнит-тесты и тестируют кейсы. Всё верно.

Ну may be

Там только один сайд эффект - корова сдохла, который можно получить предварительно покормив а потом побегав. Т.е. Участвуют 2 операции и 1 эффект. Что в итоге мы из этого тестировали?

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

Там только один сайд эффект - корова сдохла, который можно получить предварительно покормив а потом побегав. Т.е. Участвуют 2 операции и 1 эффект. Что в итоге мы из этого тестировали?

Настоящая живая корова так и работает. У неё нет геттера сытости. Есть только событие аццкого крика когда она голодная.

Настоящая живая корова так и работает. У неё нет геттера сытости. Есть только событие аццкого крика когда она голодная.

Я с этом не спорю, но для этого теста надо включать несколько методов. В итоге у нас сломан кейс и не понятно какой конкретно метод - мы неверно покормили, неверно побегали или некорректно орем о голоде

И выходит это не совсем юнит - который тестит один функционал

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

Его и тестить

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

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

Это уже некий функциональный тест

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

Просто надо делать тест на каждый кейс

Просто надо делать тест на каждый кейс

Тест который тестит кейс норм, я не спорю. Но имеет свои ньансы и имхо не юнит (но об этом 50/50 думаю)

И выходит это не совсем юнит - который тестит один функционал

Это как раз настоящий юнит-тест, тестирующий конкретный кейс поведения юнита (объекта)

И выходит это не совсем юнит - который тестит один функционал

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

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

В моем понимании это именно так, так как при тестировании всего кейса - какой метод сломался не известно. Плюс сложность и количество тестов растёт. Например кормежка имеет 5 условий (это 5 проверок), бег 5 условий. При тестировании отдельно - это 10 тестов, при тестировании совместно - это 25 тестов каждый из которых ещё и больше по объёму. Ну это образно, смысл я думаю передал

что поделать, раз корова такая многофункциональная...

Я бы отнёс такой тест - к функциональным, если говорить о тестировании всего жизненного цикла коровы по её публичным интерфейсам

В моем понимании это именно так, так как при тестировании всего кейса - какой метод сломался не известно. Плюс сложность и количество тестов растёт. Например кормежка имеет 5 условий (это 5 проверок), бег 5 условий. При тестировании отдельно - это 10 тестов, при тестировании совместно - это 25 тестов каждый из которых ещё и больше по объёму. Ну это образно, смысл я думаю передал

Все тесты тестируют кейсы. Разница только в размере цели. Юнит-тесты тестируют один юнит (объект), функциональные тестируют систему объектов и возможно инфраструктуру, приёмочные – всё приложение.

Все тесты тестируют кейсы. Разница только в размере цели. Юнит-тесты тестируют один юнит (объект), функциональные тестируют систему объектов и возможно инфраструктуру, приёмочные – всё приложение.

Ну есть разница вызвать в тесте 1 метод или 10 и думать какой из них сломался.

Все тесты тестируют кейсы. Разница только в размере цели. Юнит-тесты тестируют один юнит (объект), функциональные тестируют систему объектов и возможно инфраструктуру, приёмочные – всё приложение.

Функциональные тестируют функциональные требования, про 1 или несколько объектов - вроде нет особенностей. Вот жиизненный цикл коровы - по мне больше подходит к функциональному тесту

В моем понимании это именно так, так как при тестировании всего кейса - какой метод сломался не известно. Плюс сложность и количество тестов растёт. Например кормежка имеет 5 условий (это 5 проверок), бег 5 условий. При тестировании отдельно - это 10 тестов, при тестировании совместно - это 25 тестов каждый из которых ещё и больше по объёму. Ну это образно, смысл я думаю передал

> Например кормежка имеет 5 условий (это 5 проверок), бег 5 условий... Будет 25... Будет 5 на кормление, 5 на бег и 2 на кончину.

> Например кормежка имеет 5 условий (это 5 проверок), бег 5 условий... Будет 25... Будет 5 на кормление, 5 на бег и 2 на кончину.

Комбинации методов могут давать разные результаты. Это не обязатлеьно 25, но может бытьи не 10. Это не условия что if(true) Throw.

Функциональные тестируют функциональные требования, про 1 или несколько объектов - вроде нет особенностей. Вот жиизненный цикл коровы - по мне больше подходит к функциональному тесту

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

Комбинации методов могут давать разные результаты. Это не обязатлеьно 25, но может бытьи не 10. Это не условия что if(true) Throw.

У коровы не могут давать

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

Если юниты тестируют функциональные требования, что такое функциональные тесты, которые в своем определении тестируют функциональнеы требования?

У коровы не могут давать

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

У коровы не могут давать

Как бизнес скажет, то и будем прогать.

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

Лол, но да)))

Короче есть фция которая считает производную. Внутри она использует другую фцию которая считает значение икс от игрэк. Нужно ли нам тестировать другую внутреннюю фцию или нет?

Если юниты тестируют функциональные требования, что такое функциональные тесты, которые в своем определении тестируют функциональнеы требования?

> Что такое функциональные Это проблемы терминологии. В разных фреймворках их называют то фича-тестами, то HTTP-тестами, то интеграционными.

> Что такое функциональные Это проблемы терминологии. В разных фреймворках их называют то фича-тестами, то HTTP-тестами, то интеграционными.

У нас теория тестирования дробится на фреймворки? Фрейморки диктуют правила? Не знал.

Короче есть фция которая считает производную. Внутри она использует другую фцию которая считает значение икс от игрэк. Нужно ли нам тестировать другую внутреннюю фцию или нет?

Если она внутренняя, то протестировать не получится

Еще есть энд ту энд тестирование

Если она внутренняя, то протестировать не получится

Ну вот. А чел спрашивает как сделать её публичной чтобы протестировать

У нас теория тестирования дробится на фреймворки? Фрейморки диктуют правила? Не знал.

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

Короче есть фция которая считает производную. Внутри она использует другую фцию которая считает значение икс от игрэк. Нужно ли нам тестировать другую внутреннюю фцию или нет?

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

Юнит тесты тестируют юниты. Что такое юниты каждый решает сам )

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

В итоге для одних программистов юнит-тесты являются функциональными, а для других не являются

Или например сделал ты фасад над другими классами и клиент использует фасад. Стоит ли тестировать то что использует фасад под капотом? В идеале каждый класс должен быть протестирован. На практике будет слишком много тестов а главное при изменении внутренних механизмов надо будет править тесты

Или например сделал ты фасад над другими классами и клиент использует фасад. Стоит ли тестировать то что использует фасад под капотом? В идеале каждый класс должен быть протестирован. На практике будет слишком много тестов а главное при изменении внутренних механизмов надо будет править тесты

Клиент использует http апи фасад, стоит ли писать юниты вообще ...

Клиент использует http апи фасад, стоит ли писать юниты вообще ...

Я считаю что нет )