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

наивно)

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

а как ты думаешь зачем я воркшопы буду делать?)

и код ревью?)

у нас типа... больше одного проекта) аутсорс и все такое

вообще тут хорошая стори появляется

наивно)

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

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

а как ты думаешь зачем я воркшопы буду делать?)

и в опенсорс это выложить да да

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

во первых, проверять новый функционал проще что ничего не отвалилось

....они так и делают

чел, у меня не джуны

во вторых новый функционал будет с тестами)

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

а мне надо юниты и tdd

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

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

и с тех пор везде их форсю

было это году в 2013

или 2012

и ты пишешь юнит тесты или таки приемочные?

property based testing юзал

?

я стараюсь создавать классы в tdd

прежде всего представить как это будет использоватся пользователем(другим программистом)

и сделать максимально удобно ему

тут маленький нюанс - либки просто

когда это получается написать тест просто

а потом уже реализация

скажи - ты на своих проектах именно tdd практикуешь или atdd?

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

не совсем знаю в чем разница в atdd?

acceptance test driven...

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

тут от проекта зависит

тут от проекта зависит

типа "если проект на 2 месяца а потом ему смерть то можно не писать тесты"?

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

а новый функционал?

типа "если проект на 2 месяца а потом ему смерть то можно не писать тесты"?

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

типа "если проект на 2 месяца а потом ему смерть то можно не писать тесты"?

разве нет?

а новый функционал?

от ситуации

на текущей работе

разве нет?

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

в первую очередь я смотрю на команду

от ситуации

ну то есть тесты ты полюбил но изменяешь

в первую очередь я смотрю на команду

что мешает команде?

уровень

джуны?

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

чем отсутствие юнит теста

ясно...

опять же скажу кэпство

если в проекте лапша

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

с кучей магии

а там тебе и нормальный CI, и нормальное CD

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

и ускорение пайплайна разработки

далее с увеличением количества тестов

скорость сборки замедлится

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

они и не должны, они должны предоставлять определенный уровень надежности

доводилось работать над проектом где компиляция в java была более 8 часов

скорость сборки замедлится

ты про юнит тесты или про приемочные?

и требовала 16гб рам

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

тесты исполнялись еще дольше

ты про юнит тесты или про приемочные?

в том числе и про юнит

тесты исполнялись еще дольше

юнит тесты... 8 часов...

8 часов компиляция

в том числе и про юнит

давай ТОЛЬКО про юнит тесты

исходных кодов в java

без каких либо тестов

создание jar файлов

8 часов компиляция

не пробовали решить эту проблему?

и потом поверх этого надо было стартовать юнит тесты

и потом поверх этого надо было стартовать юнит тесты

как так поверх?

ну то есть для того что бы заранать юнит тесты тебе не надо собирать jar

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

8 часов

не пробовали решить эту проблему?

модульность и сборка модулей только тех что надо

ты можешь в несколько потоков компилить только то что надо для юнит тестов

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

....

мне кажется что ты что-то выдумываешь

ну да

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

согласен

надо собирать модули

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

это если он у тебя разбит на разные jar файлы

это если он у тебя разбит на разные jar файлы

да не надо тебе разбивать руками ничего

у тебя каждый юнит тест будет jar-ой и он будет включать в себя только те зависимости которе ему нужны

очень много очень маленьких модулей

которые быстро собираются и быстро компилятся

хз что там компилятор 8 часов ражал

только если jni какое юзалось и что-то на Си собиралось

тогда поверю

но опять же - это не должно влиять на юнит тесты

ладно не верь

я не верю больше в тот факт что никто не подумал что "батюшки святы, надо оптимизировать процесс сборки ибо 8+ часов для получения командой фидбэка о проделанной работы это высшей степени не эффективно"

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