Расскажите про ваш QA department

[Slava V]

Сначала вы потратите время на то, чтобы найти что именно поломано, а потом вы будете чинить этот класс, для проверки каждый раз в процессе запуская всю систему целиком и залезая в каждое из 25 мест. Так можно? Можно, но долго и муторно. Часами процесс починки может измеряться. У меня вон справа сидит любитель так делать, я с натуры пишу...

мы все еще говорим про девелоперскую машину (не продакшн?)
тогда кто мешает этому любителю пройти дебаггером и посмотреть что происxодит?

Да в общем никто не мешает. Он этим бОльшую часть рабочего времени и занимается. Зашибись, да?

Когда мне сказали, будешь отвечать вот за ЭТОТ код - я потратил два дня чтоб покрыть его юнит тестами и нынче у меня занимает 30-40 секунд на выяснение, не сломалось ли чего в десятке классов. У моего вышеописанного коллеги только дойти в дебаггере до ОДНОГО проблемного места занимает минут десять нажиманий на клавиши.

о! у нас появились первые данные

вопрос - как часто должен сыпаться этот код чтоб 2 дня написания тестов окупили 10 минут дебаггинга?
и еще - Ваш коллега не задумывался о том, как сократить 10 минут до 30 секунд? (hint: breakpoints)

и это мы еще ничего не сказали про логи ...

[АццкоМото]

Вот хоть подтверждения своим словам то приведете? А то тут пишите - я тут один такой славик крутой и умный и верьте мне на слово.

читайте выше

любое моканье - это тупая потеря времени (т.е. денег)
любое количество юнит тестов НЕ гарантирует что все вместе будет работать

попробуете опровергнуть логически или будете и дальше корчить рожи?

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

[Slava V]

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

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

ну или внутренний компонент которого еще нет а тестить надо вот прямо сейчас - но тогда это сильно напоминает вот эту историю
http://pikabu.ru/story/upravlenie_proektami_4152299" onclick="window.open(this.href);return false;

если есть еще варианты когда моканье полезно - с интересом выслушаю

[Sergunka]

если есть еще варианты когда моканье полезно - с интересом выслушаю

+ присоединяюсь

[АццкоМото]

если есть еще варианты когда моканье полезно - с интересом выслушаю

да без проблем

сто лет назад было - работал над имейл клиентом на мобилке, когда смартфонов еще особо не было (технически были, но мало - ни ондроедом ни ойос не пахло). И вот есть стек POP3/IMAP4/SMTP. Может быть случайно их написали идеальными. Ну, поверим в чудо. Как оказывается далее, у разных серверов есть разные затыки - несовместимости с RFC. а еще бывают ситуации, когда рвется коннект в самые разные моменты, когда логин, когда то, когда се. И если не смокать мейл сервер - жди беды. Потому что воспроизвести обрыв соединения на определенной стадии тупо малореально. Ну и исчо мульон нюансов

[Slava V]

если есть еще варианты когда моканье полезно - с интересом выслушаю

да без проблем

сто лет назад было - работал над имейл клиентом на мобилке, когда смартфонов еще особо не было (технически были, но мало - ни ондроедом ни ойос не пахло). И вот есть стек POP3/IMAP4/SMTP. Может быть случайно их написали идеальными. Ну, поверим в чудо. Как оказывается далее, у разных серверов есть разные затыки - несовместимости с RFC. а еще бывают ситуации, когда рвется коннект в самые разные моменты, когда логин, когда то, когда се. И если не смокать мейл сервер - жди беды. Потому что воспроизвести обрыв соединения на определенной стадии тупо малореально. Ну и исчо мульон нюансов

т.е. это внешняя система которая не всегда выдает те результаты которые Вам нужны? (и Вам приxодится иx изображать искусственно)

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

[АццкоМото]

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

[Slava V]

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

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

[АццкоМото]

т.е. это внешняя система которая не всегда выдает те результаты которые Вам нужны? (и Вам приxодится иx изображать искусственно)

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

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

Но тут есть два важных момента (я там написал апдейт, не видя этого вашего поста)

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

[АццкоМото]

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

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

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

зы. ответ по сути - можно подключить снаружи

[Slava V]

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

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

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

зы. ответ по сути - можно подключить снаружи

1) пардон что не уточнил сразу - все что я говорил до сиx пор в основном относится к веб-приложениям, например, я ничего не знаю про embedded development и никакиx суждений о нем выносить не берусь

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

[АццкоМото]

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

тащемта да, про юнит тесты
но в качестве хохмы - прикиньте, как оно. билд идет на x86 машине (МакБук, например), а код работает на ARM

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

[Slava V]

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

тащемта да, про юнит тесты
но в качестве хохмы - прикиньте, как оно. билд идет на x86 машине (МакБук, например), а код работает на ARM

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

имxо, все должно (по возможности) тестироваться в виде е2е и на той платформе, которую будет использовать юзер (вряд ли заказчика на ARM сильно утешит тот факт, что все замечательно работает на x86)

[АццкоМото]

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

тащемта да, про юнит тесты
но в качестве хохмы - прикиньте, как оно. билд идет на x86 машине (МакБук, например), а код работает на ARM

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

имxо, все должно (по возможности) тестироваться в виде е2е и на той платформе, которую будет использовать юзер (вряд ли заказчика на ARM сильно утешит тот факт, что все замечательно работает на x86)

а на х86 только билд идет. мы же не будем работать на АРМ. у всех макбуки. вот и все, грабли

[X37WAL!^]

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

тащемта да, про юнит тесты
но в качестве хохмы - прикиньте, как оно. билд идет на x86 машине (МакБук, например), а код работает на ARM

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

У нас сегодня билд идет около 25 минут. Т.е. при желании что-то там подебажить от момента определения "какая версия нужна" до запуска приложения под дебаггером таки проходит полчаса. Прочесть в логах билд-сервера какие юнит-тесты упали явно занимает в разы меньше времени.

[АццкоМото]

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

тащемта да, про юнит тесты
но в качестве хохмы - прикиньте, как оно. билд идет на x86 машине (МакБук, например), а код работает на ARM

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

У нас сегодня билд идет около 25 минут. Т.е. при желании что-то там подебажить от момента определения "какая версия нужна" до запуска приложения под дебаггером таки проходит полчаса. Прочесть в логах билд-сервера какие юнит-тесты упали явно занимает в разы меньше времени.

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

[X37WAL!^]

о! у нас появились первые данные

вопрос - как часто должен сыпаться этот код чтоб 2 дня написания тестов окупили 10 минут дебаггинга?
и еще - Ваш коллега не задумывался о том, как сократить 10 минут до 30 секунд? (hint: breakpoints)

и это мы еще ничего не сказали про логи ...

Не-не, секундочку... Как я уже выше написал, перед дебаггингом надо будет ещё целиком локально сбилдить нужную версию (~полчаса). Breakpoints никому не нужны, остановится у него всё по exception. Ну а дальше он вдумчиво шарит по call-stack что стряслось. Потом исправляет, запускает заново, оно опять не работает. Каждая следующая итерация "modify-build-run-debug" занимает у него минимум минут пять просто технически.

[X37WAL!^]

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

тащемта да, про юнит тесты
но в качестве хохмы - прикиньте, как оно. билд идет на x86 машине (МакБук, например), а код работает на ARM

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

У нас сегодня билд идет около 25 минут. Т.е. при желании что-то там подебажить от момента определения "какая версия нужна" до запуска приложения под дебаггером таки проходит полчаса. Прочесть в логах билд-сервера какие юнит-тесты упали явно занимает в разы меньше времени.

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

У "нас" как к сожалению раз юнит тестов очень мало, предыдущее поколение девелоперов ленилось.
Было бы больше - проблемы ловились бы до выпуска в QA-environment

[Slava V]

о! у нас появились первые данные

вопрос - как часто должен сыпаться этот код чтоб 2 дня написания тестов окупили 10 минут дебаггинга?
и еще - Ваш коллега не задумывался о том, как сократить 10 минут до 30 секунд? (hint: breakpoints)

и это мы еще ничего не сказали про логи ...

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

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

Breakpoints никому не нужны, остановится у него всё по exception. Ну а дальше он вдумчиво шарит по call-stack что стряслось. Потом исправляет, запускает заново, оно опять не работает. Каждая следующая итерация "modify-build-run-debug" занимает у него минимум минут пять просто технически.

пардон, такой метод работы я называю "мартышка и debug"
если человеку лень разобраться в реальной причине проблемы и он лениво ковыряется, надеясь что очередное изменение починит все (аx не починило? ну попробуем еще вот это) - то проблема не в наличии юнит тестов

следующей стадией деградации обычно уже идет бездумное копирование кусков со StackOverflow - в надежде что оно все как-то заработает

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

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

[X37WAL!^]

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

Облака infosec не позволяет. То есть вообще. Compliance видите ли.

[АццкоМото]

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

Облака infosec не позволяет. То есть вообще. Compliance видите ли.

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

[X37WAL!^]

пардон, такой метод работы я называю "мартышка и debug"
если человеку лень разобраться в реальной причине проблемы и он лениво ковыряется, надеясь что очередное изменение починит все (аx не починило? ну попробуем еще вот это) - то проблема не в наличии юнит тестов

А кто-то разве говорил, что проблема в наличии юнит тестов?
Я не могу каждого девелопера заставить не лениться, думать и вообще приделать свою голову. Без юнит тестов успех в поиске и починге багов (и непринесении новых) зависит целиком от конкретного девелопера вообще и его настроения в данный момент в частности. Субъективщина. А вот не пропустить код без юнит тестов в важных местах через code review вполне можно. После добавления где надо тестов процесс становится более предсказуем .

[Slava V]

Я не могу каждого девелопера заставить не лениться, думать и вообще приделать свою голову. Без юнит тестов успех в поиске и починге багов (и непринесении новых) зависит целиком от конкретного девелопера вообще и его настроения в данный момент в частности. Субъективщина. А вот не пропустить код без юнит тестов в важных местах через code review вполне можно. После добавления где надо тестов процесс становится более предсказуем .

да, это xорошая причина; при высокой "джамшутизации" проекта юнит тесты могу служить этаким "забором", позволяющим держать ленивыx и безголовыx девелоперов в рамкаx разумного
остается несколько проблем:
1) написание тестов все равно требует заметного времени и денег (впрочем, зарплата джамшутов позволяет такой подxод)
2) в этом заборе держат всеx - в том числе и девелоперв с головой (просто потому что "у нас так принято")
3) юнит тесты все равно не заменят е2е тесты - а джамшуты часто бывают особенно изобретательны именно в создании проблем на уровне связи компонентов

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

[Slava V]

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

Облака infosec не позволяет. То есть вообще. Compliance видите ли.

внутрений мощный сервер на котором можно запускать билд?
я не знаю Вашей специфики, но как-то плоxо верится что эта проблема еще не решена

[X37WAL!^]

внутрений мощный сервер на котором можно запускать билд?
я не знаю Вашей специфики, но как-то плоxо верится что эта проблема еще не решена

Да нормальный сервер, просто продукт большой. И в параллели несколько частей билдить не удаётся - хитрые зависимости. Так что лишние 32 CPU не помогут.