думаю, кончились аргументы

Нужно знать внутренности гема.

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

_гема_

ты знаешь внутренности совего приложения.

В гемы редко надо лезть.

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

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

я ж не знаю об энтом

я вот юзаю голый девайс например

написал себе after_create в модельке

expect { post :create }.to send_sms

expect { create(:user) }.to send_sms

ты скучный, даже не поспорить

хочешь перейдем к оскарблениям?

думаю, кончились аргументы

хочешь перейдем к оскарблениям?

Ты ранишь мою ранимую психику.

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

не, скучно

трата времени же ну. Я лучше код писать буду.

а вот мокаю ответ я неправильно, это очевидно. Мокать надо как то еще.

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

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

тестировать гем при этом не нужно

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

Оно так и работает, я же реализацию матчера не показывал еще.

лучше не надо, а то у меня будут аргументы

Так даже интереснее

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

Хоть кто то поддержал что процесс можно выстроить. Спс

Процесс можно выстроить, если есть сильный техлид

Процесс можно выстроить, если есть сильный техлид

достаточно стремления к порядку

Недостаточно, ты можешь не иметь достаточно веса в команде.

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

Есть менеджеры которые требуют фичи, есть другие разработчики.

я тоже много чего "внедрил", только постоянно это выдерживать сложно.

Ну так он сам говорил что чуть ли не с первых рельс сидит.

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

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

+

+

Ты внедрил SVN?

Есть менеджеры которые требуют фичи, есть другие разработчики.

вообще это часть работы представь что ты ООО "Алекс Илизаров" а не штатный разработчик твоя задача завоевать доверие заказчика, чтобы всякие менеджеры заказчика не трахали тебе мозг

я тоже много чего "внедрил", только постоянно это выдерживать сложно.

На отлаженные процессы не много сил уходит на поддержку. После того как процесс отлажен, надо настроить метрики, они то и помогают облегчить поддержку.

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

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

Ты внедрил SVN?

Чуть менее чем 10 лет назад. Тоже был зеленым тогда.

А, ну я не знал что ты тоже старый.

Я бы назвал это опытом)

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

Ну я однажды донес наконец до ПМ-а, что если команда кладет на тесты, а я утром прихожу на работу а мой код убит, то я никогда не сдам фичу. Но было уже поздно, стартап убили :)

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

Но это же не означает что это не реально.

Я тоже кстати насаждал активное тестирование в проекте. Не то чтобы очень получилось.

Фронту тестирование навязать вообще сложно, а с бэком тесты делались кое как.

Плюс постоянное ощущение что ты "тормозишь" команду следуя более менее процессу.

Ну и адекватный ПМ обычно прислушивается к разрабам. По крайне мере в моем опыте было так.

Я тоже кстати насаждал активное тестирование в проекте. Не то чтобы очень получилось.

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

Ну вот таже история.

это не повод опускать руки :) это повод поднять биту

Если ты техлид то у тебя есть весь чтобы навязать процессы и объяснить их необходимость. Обычный разработчик может не иметь такой вес.

Ну или повод сменить работу (

зажимаешь по одному в коридоре и пиздишь

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

Самое сложно это бороться с ленью

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

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

Пока не начнешь тестировать не поймешь как это круто и удобно.

Тебе кажется что это трата времени.

ERROR: S client not available

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

Какой даклад?

тестирование, мутации, всякое такое

а, жаль.

Я бы послушал про практику мутационного тестирования.

слишком узко мыслю :)

Иногда тестирование и в правду бывает лишним

Ну да, им подавай репликацию постгреса на живую.

Иногда тестирование и в правду бывает лишним

Не знаю таких кейсов. Расскажи.

Тут поможет простая аналитика.

Ну да, им подавай репликацию постгреса на живую.

куда там на одном докладе рассказывали как они управляют релизами про помощи внимание: "Git"

Ну да, им подавай репликацию постгреса на живую.

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

Не знаю таких кейсов. Расскажи.

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

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

Всегда стоит, лол

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

Если ты делаешь сначала код а потом тесты то это уже серьезные накладные расходы, да.

Ты про автотесты?

В общем то да.

Ну да, им подавай репликацию постгреса на живую.

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

Я думал мы про них и говорим.

Как часто у тебя срабатывают тесты (то есть находят баги)?

Как часто у тебя срабатывают тесты (то есть находят баги)?

Учитывая кривость бизнес процессов - я пират красного моря.

Напрмиер ты сделал 100 коммитов, каждый протестил, сколько коммитов у тебя не пройдут тесты?

Например у меня постоянно коллеги ломали мой фукнционал.

Как часто у тебя срабатывают тесты (то есть находят баги)?

я правлю баги зачастую до того как их репортят

Я могу увидеть кейс который я изначально не видел, потому что я сел и подумал в TDD

Опять же, дело не в коммите, дело в поддержке.

У меня guard-rspec (раньше guard-minitest), так что у меня почти не бывает красных коммитов.

А вот потом когда что то правишь и где то ВНЕЗАПНО отвалилось, ты видешь это в тестах.

Как часто у тебя срабатывают тесты (то есть находят баги)?

а вообще тесты падают очень часто при разработке фичи, у меня покрытие к счастью ~90%

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