азия дешевле чем киев)

такой дом как у меня в тае будет стоить в 2 раза дороже

+ интернет хуже

+ еды нет или дорогая привычной которая мне надо

но я думаю попробовать все равно зимовку в азии в эту зиму

за 6к снимешь кондо 1к, с бассейном, спортзалом, свежий дом

ну если не в центре бангкока или у воды на островах в сезон)

если не принципиально чуть подальше от города можно за 7 дворец найти) смотрел такой с бассейном недавно

это в гривнах?????

это в гривнах?????

да

что то оооооооооооооооочень дешево

за 6к снимешь кондо 1к, с бассейном, спортзалом, свежий дом

а у меня 100кв2 + гараж + 10 соток возле озера в лесу и 10 минут до Киева на машине по норм трассе

15 тысяч рублей дворец

что то оооооооооооооооочень дешево

у нас цены сильно упали как война началась. раньше мою квартиру можно было за 120к продать, сейчас и за 50 не выйдет

а у меня 100кв2 + гараж + 10 соток возле озера в лесу и 10 минут до Киева на машине по норм трассе

над глянуть, а то по 12к отваливать за хату в киеве как-то надоело)

у нас в сутки столько стоит аренда домика в подмосковье) и это не дворец а прсотая дачка с баней

над глянуть, а то по 12к отваливать за хату в киеве как-то надоело)

ты трезво подумай, нужен ли тебе тот Киев. я подумал и оказалось что нет. + малой родился и ему тут вообще круто с батутом, личной площадкой итд

у нас цены сильно упали как война началась. раньше мою квартиру можно было за 120к продать, сейчас и за 50 не выйдет

120к квартира????

у нас в сутки столько стоит аренда домика в подмосковье) и это не дворец а прсотая дачка с баней

ну я вам сочуствую) Переезжай сюда.

120к квартира????

долларов

А, ну ок, а то я вообще офигел

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

ну не сказал бы что в буче жилье сильно дешевле

1-2к разницы, вот щас смотрю

ну у меня же не буча и не ирпень, тупо лес ))))

на самом въезде в Ирпень

а "дальше" я имел ввиду начиная от Ворзеля и еще дальше

в донецке наверно вообще просели хаты

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

а как мы с модульных тестов перешли к панелькам?

в донецке наверно вообще просели хаты

в Донецке у знакомых хаты поотжимали тупо

там у кого ствол, того и хата

ну да, эт очевидно

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

вопрос в рамках, что для тебя "тривиальная логика, которую не хочется покрывать тестами".

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

ответ в том, что считать модулем. модуль != класс. тест описывает внешнее поведение модуля, который внутри может быть одним гигантским классом или десятком подмодулей. ты можешь его внутри рефакторить как пожелаешь, тест при этом трогать не нужно. Случай с простой связующей штукой, которую ты описываешь, это либо продукт рефакторинга (тогда тест уже есть, это тест на внешнюю штуку), либо нечто новое, важное для бизнеса, что имеет большой потенциал для роста и усложнения. и в последнем случае очень хорошо поведение этого модуля начать описывать в виде тестов с самого начала, пока оно не разрослось, чтобы потом можно было легко рефакторить при необходимости.

p.s. я тут думаю воркшопик по тестированию провести, и сильно нуждаюсь в примерах "проблем" разработчиков с тестами.

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

вопрос в рамках, что для тебя "тривиальная логика, которую не хочется покрывать тестами".

например у тебя есть event listener, который подписан на события какие-то и просто вызывает нужные сервисы entity manager, который сам по себе почти ничего не делает инфраструктурные штуки и тд

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

например у тебя есть event listener, который подписан на события какие-то и просто вызывает нужные сервисы entity manager, который сам по себе почти ничего не делает инфраструктурные штуки и тд

первое два - согласен, хотя с entity manager - он по хорошему не должен быть размазан повсюду и как следствие ты подменяешь просто чуть другие зависимости. А вот "инфраструктурные штуки" - тут много чего может быть.

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

а еще есть компонентные)

граница - область процесса. Если у тебя тесту надо выходить за пределы пространства памяти процесса (внешний мир относительно модуля), то он уже не юнит.

ну или по другому - юнит тесты - быстрые тесты

ответ в том, что считать модулем. модуль != класс. тест описывает внешнее поведение модуля, который внутри может быть одним гигантским классом или десятком подмодулей. ты можешь его внутри рефакторить как пожелаешь, тест при этом трогать не нужно. Случай с простой связующей штукой, которую ты описываешь, это либо продукт рефакторинга (тогда тест уже есть, это тест на внешнюю штуку), либо нечто новое, важное для бизнеса, что имеет большой потенциал для роста и усложнения. и в последнем случае очень хорошо поведение этого модуля начать описывать в виде тестов с самого начала, пока оно не разрослось, чтобы потом можно было легко рефакторить при необходимости.

если у тебя только 1 тест на весь модуль, в котором с десяток классов, у которых у каждого будет по 5 различных кейсов, то это сколько должно быть кейсов чтобы проверить все? 5^10?

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

если у тебя только 1 тест на весь модуль, в котором с десяток классов, у которых у каждого будет по 5 различных кейсов, то это сколько должно быть кейсов чтобы проверить все? 5^10?

вот я тоже не понял, на вид - просто интеграционный/компонентный тест.

оно конечно может внутри например какие-то объекты свои юзать... но это уже детали реализации. Веселье то с зависимостями

по сути через юнит тесты мы поведение объектов декларируем, контракты.

и они являются гарантом что контракт будет соблюдаться. И если добавить к этому open/close то в целом вообще все красиво выходит.

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

смоук тесты то вообще отдельная тема

смоук тесты то вообще отдельная тема

не путай, это не смоук тесты.

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

нет ли сбоев

я железо не тестирую, так что хз как это делается

я железо не тестирую, так что хз как это делается

ну я тоже, просто в универе гоняли по этим вещам.

у меня в универе все проще было. перепад напряжения - вырубаем всю подсеть сеть нахер) перегрев - туда же

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

а диагностика это не для смертных)

если у тебя только 1 тест на весь модуль, в котором с десяток классов, у которых у каждого будет по 5 различных кейсов, то это сколько должно быть кейсов чтобы проверить все? 5^10?

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

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

не факт

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

она делала себе дела и была покрыта тестами

и она взаимодействовала с другой херней

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

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

"покрытие" - дело второстепенное по сути.

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

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

А еще для новичков, пробующих TDD - это интересно упражнение. Пока напишешь тесты, забыл что вообще от системы хотел

ERROR: S client not available

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

ты смотрел "Integrational tests are scum"?

А еще для новичков, пробующих TDD - это интересно упражнение. Пока напишешь тесты, забыл что вообще от системы хотел

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

ты смотрел "Integrational tests are scum"?

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

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

не совсем так. Интеграционные тесты строго там где надо - все остальное - юнит тесты. И чуть-чуть e2e что бы быть уверенным что в сборе все работает.

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

Само собой. Это я свое знакомстмо с TDD вспомнил)

я когда с TDD знакомился думал что оно про тесты...

не совсем так. Интеграционные тесты строго там где надо - все остальное - юнит тесты. И чуть-чуть e2e что бы быть уверенным что в сборе все работает.

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

опять названия

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

всеравно не понятно

у меня чуть проще - если у тестируемой штуки в зависимостях все хорошо и там есть четко прописанные контракты, и зависимости стабильнее чем мы сами - тестим юнитами. Интеграционные - все остальное (репозитории например. там зависимость с крайне херовым контрактом да еще и не шибко стабильная реализация).

другое дело что у тебя ~80 проекта должно подходить под описание того что можно юнитами покрыть. И проблемы от того что как раз таки контрактов четких нет

и с зависимостями все плохо

например те же клиенты для апишек я бы юнитами спокойно покрывал

у меня есть вполне себе четко определенный контракт. Guzzle. И я могу его замокать и смотреть как мой код будет реагировать если пустой json придет, или ConnectionException выпадет....

но это если апишку ты можешь стабильной зависимостью назвать

если это какой-нибудь Вася пишет который рядышком сидит и он ломает обратную совместимость по 5 раз на дню - там только интеграционные

ну вот взять ту же тупую апишку, что ты там юнит тестами собрался покрывать?

ну вот взять ту же тупую апишку, что ты там юнит тестами собрался покрывать?

поведение моей штуки которую я накрутил поверху)

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

который рулит в репос/сервис и оттуда выгребает его

а какое у этого метода поведение?

и отдает обратно + какой-нибудь линк сгенерит для ответа

должен ли он сделать например репит запроса если все плохо

и отдает обратно + какой-нибудь линк сгенерит для ответа

что отдает? json?

ну ок, еще и обработку ошибок если юзер не найден

да

или объект? мэппинг какой, трансформация есть?

ну ок, еще и обработку ошибок если юзер не найден

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

чем тебе не логика?

слишком линейная

какая разница?

ты весь код в тесте дублируешь