и чо?

У меня у одного github тупит?

нет

хух

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

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

а то что его в стол потом отправят - посторонний вопрос

могут вообще электричество выключить

но логике это не поддается

ты пишешь больше в два раза или в три

как оно может писаться быстрее?

или обьясни в чем фокус

ты пишешь больше в два раза или в три

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

или обьясни в чем фокус

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

какой то сайт у тех модных ребят со слишком мелкой типографикой

как оно может писаться быстрее?

понятно если ты написал метод to_s то с тестами его писать медленнее в 4 раза но зато есть гарантия, что твоим to_s не пользовался никто, если тесты прошли

да тот же переход в консоль reload! rails c вверх-вверх ентер отнимает кучу времени

а как решать проблему с юнит-тестами, если их много допустим 70% тестов после какого-то изменения нужно исправлять?

а как решать проблему с юнит-тестами, если их много допустим 70% тестов после какого-то изменения нужно исправлять?

да, это расходы, а не проблема

70% тестов... в одном файле весь проект?

70% тестов... в одном файле весь проект?

ЭЭЭ это как?

ну я с трудом представляю как могут 70% рухнуть

вот вот

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

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

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

интеграционное тестирование делается руками по инструкции?

нет, автоматизированно

ну это же тоже тесты

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

тесты часть кода, а не тесты отдельно, код отдельно

оффтоп: "ваш флоу говно" (ц) Иван Веревкин

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

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

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

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

то есть они могут и не отвалиться

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

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

если код воняет его сложно тестировать - отличный индикатор

но код то не должен вонять

если он писался сначала на тестах?

чего это не должен?

не должен

Антон говорил что тесты не позволяют писать говнокод

говна понаписать можно хоть с тестами, хоть без

чего это не должен?

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

это все от лени

но если приходится править большое количество юнит-тестов уже теряется уверенность что все работает как надо, как это происходит при test-first подходе?

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

всё равно говнокод можно написать, даже с тестами

но сложнее конечно

да и лень

то есть изменения в тестах происходят как реакция на изменения в коде

можно написать гавнокод и покрыть тестами

тесты скажем так сужают пространство для говнокодера, но всё равно его хватает))

обычно так и делают

никто тесты до не пишет, обычно...

никто тесты до не пишет, обычно...

как это никто? я пишу

мон сеньер писал

ну мало людей. Я вкурсе

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

[In reply to Vitaly Simakov] фокус в том что тесты не дают писать говно

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

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

ну не, дайте тесты, я напишу в них гавно)

????

[In reply to Vitaly Simakov] фокус в том что тесты не дают писать говно

не воспринимай треп в чате как истину от и до

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

Тесты тестят код. Неважно гавно код или нет

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

ERROR: S client not available

лижбы задачи покрывал которые тестируем

Короче если фирма нанимает тебя и не требует тесты, или не тестирует код лучше туда не ходить

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

очень правильно

Да

а routing в рельсе кто-нибудь тестирует?

да

это самое простое

но можно не тестировать, пока нет кастомных роутов

с констрейнами

а ассоциации в моделях?

Констрейны ток

но совсем говнокод сложней тестировать

Ассоциации да

еще инверсить хорошо

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

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

а смысл в тестировании вообще всего раутинга?

Вообще лучше тестить интеграционные 100%, плюс модели 100%, плюс коллбеки и бизнес логику

Контроллеры в исключительных случаях

+ мутации

роуты тестить если сложная логика с constraints

и будет счастье

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

И чем больше тестишь, тем легче потом. Уже заранее тесты писать начинаешь

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

отчегож ты бухаешь

?

раз тесты пишешь

жизнь говно :)

ну это сомнительный повод

отнюдь