Тайм-бомбы в проектах = вечный заработок

[IvanGrozniy]

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

Я чуть со стула не упал... Как говорится "и эти люди запрещают нам ковыряться в носу!"

[IvanGrozniy]

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

А вообще - было бы желание, можно было бы сделать такую тайм-бомбу, к которой хрен подкопаешься. Зависимость от внешнего сервиса прописал и не оплатил его. Вот тебе и тайм-бомба.

так почему тесты валятся выяснили?
у меня здесь несколько причиню. И первая из них: о тестовых данных не позаботились, особенно если много зависимостей между сущностями.
Т.е. взяли то, что сейчас есть в базе, и захардкодили. потом что-то в базе поменялось/удалилось - этих объектов уже нет.
По более правильному пути, нужно каждый тест делать изолированными, т.е. в before методе создать все необходимые объекты, а в after методе удалить все созданные объекты.
Потом все это обернуть в CI и гонять, через заданный промежуток времени. Хорошо ещё разбить по приоритету. P0 запускать каждый билд на тестовый сервер, а P3 можно только в регресию прогонять. т.к. апи 1 тест это 1 секунда, а 100 тестов уже полторы минуты, а 1000 уже никто ждать не будет.

Разве база данных не должна изолироваться от логики и логика тестироваться без базы с dependency injection и мок данными? Или вы больше об integrational testing говорите?

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

Сейчас конечно зависит от компании, но у меня сложилось мнение, что специально нанимают автотестеров для поддержания тестов на легаси коде. В придачу к разработке всяких large tests.

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

[nyekimov]

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

А вообще - было бы желание, можно было бы сделать такую тайм-бомбу, к которой хрен подкопаешься. Зависимость от внешнего сервиса прописал и не оплатил его. Вот тебе и тайм-бомба.

так почему тесты валятся выяснили?
у меня здесь несколько причиню. И первая из них: о тестовых данных не позаботились, особенно если много зависимостей между сущностями.
Т.е. взяли то, что сейчас есть в базе, и захардкодили. потом что-то в базе поменялось/удалилось - этих объектов уже нет.
По более правильному пути, нужно каждый тест делать изолированными, т.е. в before методе создать все необходимые объекты, а в after методе удалить все созданные объекты.
Потом все это обернуть в CI и гонять, через заданный промежуток времени. Хорошо ещё разбить по приоритету. P0 запускать каждый билд на тестовый сервер, а P3 можно только в регресию прогонять. т.к. апи 1 тест это 1 секунда, а 100 тестов уже полторы минуты, а 1000 уже никто ждать не будет.

Разве база данных не должна изолироваться от логики и логика тестироваться без базы с dependency injection и мок данными? Или вы больше об integrational testing говорите?

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

Сейчас конечно зависит от компании, но у меня сложилось мнение, что специально нанимают автотестеров для поддержания тестов на легаси коде. В придачу к разработке всяких large tests.

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

Ага. Или написать вспомогательные мок классы и тестировать их ))

[Zachet]

Однако не думал что в таком количестве мест не практикуются код ревьюс. Представляю какой там срач в коде.

[nyekimov]

Однако не думал что в таком количестве мест не практикуются код ревьюс. Представляю какой там срач в коде.

Наличие код ревью вовсе не означает его правильное проведение. На мелкой конторе, первой для меня в юс, код ревью был формальностью, апрув мердж. Все.
На второй компании я стал одним из тех, кто поднимает планку. Но я этим разозлил одного корейца, что он стал искать проблемы с отступами и запятыми даже в тестовом коде. Что я лично считаю оверкилом и pita. На текущей компании опять же только я и ещё один два чувака реально делают ревью и кидают предложения об улучшении тем, кто городит свой велосипед вместо использования общепринятых паттернов. Но в общем это практически всегда неблагодарная работа, горе разработчики часто обижаются.
Даже видел интервью бывшего гуглера нынче тесловца, если память с Теслой не изменяет. И он жаловался. Что в Гугл в коде муха не пролетит и это чаще его парило. И мол в тесла такого нет. Сам код пишешь, как эксперт, сам его потом и сапортишь.

[ystar]

Однако не думал что в таком количестве мест не практикуются код ревьюс. Представляю какой там срач в коде.

Наличие код ревью вовсе не означает его правильное проведение. На мелкой конторе, первой для меня в юс, код ревью был формальностью, апрув мердж. Все.
На второй компании я стал одним из тех, кто поднимает планку. Но я этим разозлил одного корейца, что он стал искать проблемы с отступами и запятыми даже в тестовом коде. Что я лично считаю оверкилом и pita. На текущей компании опять же только я и ещё один два чувака реально делают ревью и кидают предложения об улучшении тем, кто городит свой велосипед вместо использования общепринятых паттернов. Но в общем это практически всегда неблагодарная работа, горе разработчики часто обижаются.
Даже видел интервью бывшего гуглера нынче тесловца, если память с Теслой не изменяет. И он жаловался. Что в Гугл в коде муха не пролетит и это чаще его парило. И мол в тесла такого нет. Сам код пишешь, как эксперт, сам его потом и сапортишь.

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

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

в тесле хорошо бы тестировать перед тем как стекла бить.

[nyekimov]

Однако не думал что в таком количестве мест не практикуются код ревьюс. Представляю какой там срач в коде.

Наличие код ревью вовсе не означает его правильное проведение. На мелкой конторе, первой для меня в юс, код ревью был формальностью, апрув мердж. Все.
На второй компании я стал одним из тех, кто поднимает планку. Но я этим разозлил одного корейца, что он стал искать проблемы с отступами и запятыми даже в тестовом коде. Что я лично считаю оверкилом и pita. На текущей компании опять же только я и ещё один два чувака реально делают ревью и кидают предложения об улучшении тем, кто городит свой велосипед вместо использования общепринятых паттернов. Но в общем это практически всегда неблагодарная работа, горе разработчики часто обижаются.
Даже видел интервью бывшего гуглера нынче тесловца, если память с Теслой не изменяет. И он жаловался. Что в Гугл в коде муха не пролетит и это чаще его парило. И мол в тесла такого нет. Сам код пишешь, как эксперт, сам его потом и сапортишь.

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

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

в тесле хорошо бы тестировать перед тем как стекла бить.

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

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

[Palych]

А есть были ли прецеденты когда за такие бомбы (после предъявления их начальству) действительно получали деньги? Или хотя бы избегали увольнения достаточно долго.

[liamkin]

А есть были ли прецеденты когда за такие бомбы (после предъявления их начальству) действительно получали деньги? Или хотя бы избегали увольнения достаточно долго.

В-основном, это используется как йоб секьюрити. И причем все в курсе. "Наш незаменимый специалист!".