Программирование по принципу тесты вперёд TDD

[Kittiket]

Ну хорошо, сформулирую иначе. Много ли разработчиков в 1998 понимало принцип и философию TDD?

Я и сейчас не понимаю. А муж вон от объектов плюется. Но я вроде уже жаловалась как я ему книжку по джаве дала поизучать.

 

[Kittiket]

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

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

 

[Boris]

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

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

но и проверка что если тут вытащили носик, там хвостик не отвалился.

млин, но это же и есть работа ПРОГРАММИСТА. Не кодера сраного которых щас пачками за 3 мес "готовят".

Тесты (уже написанные) позволяют легко увидеть

если меняется функционал - меняются и тесты, верно?
Тогда снова, вместо одной команды нормальных людей, имеем две, где одни следят за косяками других?
Чем сложнее система, тем выше вероятность отказа.
Я правда не понимаю и мне очень любопытно.
Ну не дураки же (я надеюсь) ЭТО ВСЕ придумали. (но это не точно)

просто потому что он слишком большой.

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

 

[Kittiket]

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

Муж тоже на такое жалуется и говорит что программисты халявщики.

 

[irinaR]

Муж тоже на такое жалуется и говорит что программисты халявщики.

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

 

[Boris]

как мне нехватает возможности проверить мою собственную программу

что вам мешает кроме отсутствия времени?

 

[Kittiket]

млин, но это же и есть работа ПРОГРАММИСТА. Не кодера сраного которых щас пачками за 3 мес "готовят".

у вас гиг кода, большую часть которого вы в глаза не видели и весьма приблизительно представляете что он делает. Писался в течение 10 лет разными людьми под разные требования. И продолжает писаться 10 скрам командами одновременно с вами. Не бывает таких гениальных программистов которые могут объять это все и гарантировать что ничего никогда от их изменений не сломается. Иногда конечно ты знаешь что задача маленькая и изолированная. А иногда - вроде все хорошо сделал, а хвостик на другом конце отвалился. Это нормально совершенно.

 

[Степан Бабкин]

Но иногда так ппц лениво, особенно эти чертовы геттеры.

Stable

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

Я правда не понимаю и мне очень любопытно.

Потому что не испытал боли. Можно сколько угодно объяснять, что такое "горячий утюг", но лучше дать один раз потрогать ?

 

[Kittiket]

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

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

 

[irinaR]

что вам мешает кроме отсутствия времени?

специфика. я программист АСУ ТП и работаю с очень большими машинами (сейчас, например, 120 приводов, больше 12000 полевых сигналов, чужие приблуды типа машинного зрения и т.д). под каждую такую машину программы пишутся индивидуально, а при том что у нас и среда разработки развивается и у заказчиков свое понимание прекрасного каждый раз - переписываются в том числе базовые блоки библиотек.
невозможно написать всю логику начиная от управления каждыми клапаном - двигателем - тормозом, реакции на каждый датчик и каждую кнопку и заканчивая общей глобальной логикой работы всей линии и протестировать без машины, для которой это все написано.
поэтому и тянутся у нас пусконаладки по полгода ?

 

[Kittiket]

Stable

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


Потому что не испытал боли. Можно сколько угодно объяснять, что такое "горячий утюг", но лучше дать один раз потрогать ?

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

 

[Boris]

А иногда - вроде все хорошо сделал, а хвостик на другом конце отвалился. Это нормально совершенно.

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

Писался в течение 10 лет разными людьми под разные требования.

 

[Kittiket]

специфика. я программист АСУ ТП и работаю с очень большими машинами (сейчас, например, 120 приводов, больше 12000 полевых сигналов, чужие приблуды типа машинного зрения и т.д). под каждую такую машину программы пишутся индивидуально, а при том что у нас и среда разработки развивается и у заказчиков свое понимание прекрасного каждый раз - переписываются в том числе базовые блоки библиотек.
невозможно написать всю логику начиная от управления каждыми клапаном - двигателем - тормозом, реакции на каждый датчик и каждую кнопку и заканчивая общей глобальной логикой работы всей линии и протестировать без машины, для которой это все написано.
поэтому и тянутся у нас пусконаладки по полгода ?

Звучит офигенно интересно но я представляю какой это гемор.

 

[irinaR]

Звучит офигенно интересно но я представляю какой это гемор.

это самая интересная работа в мире. но гемор - чудовищный, да

 

[Kittiket]

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

В моей нынешней конторе я очень много бизнес-логики не знаю не относящейся непосредственно к моей части приложения, особенно для хитрых случаев. А так есть тесты написанные теми кто разбирается в разных частях программы, ты что-то изменил и запускаешь эти тесты. Если прошли - все ок. Если не прошли - разбираешься уже, это ты неправ или тесты. Но вообще это конечно не бесплатная фича и тесты замедляют разработку и поддержка тестов обходится недешево. И не дают конечно 100% гарантии отсутствия багов. Но с ними вроде как лучше чем без них.

 

[Степан Бабкин]

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

Чисто с точки зрения код-ревьюера я бы это приветствовал. Помогает избегать многих багов. Интуитивно не все понимают, что нельзя модифицировать объекты, созданные не тобой. Но догмы - это тоже плохо.

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

О, да... Кастомизации... Мы решали так - выделяли всё что можно общее в ядро, тестировали его, а расширения уже отдельно.

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

 

[irinaR]

О, да... Кастомизации... Мы решали так - выделяли всё что можно общее в ядро, тестировали его, а расширения уже отдельно.

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

да индивидуально все каждый раз и под каждую задачу

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

 

[Kittiket]

Чисто с точки зрения код-ревьюера я бы это приветствовал. Помогает избегать многих багов. Интуитивно не все понимают, что нельзя модифицировать объекты, созданные не тобой. Но догмы - это тоже плохо.

По факту за хрен знает сколько лет я могу припомнить только несколько багов вызванных именно изменением объектов которые ты не должен был менять, а должен был сделать копию и с ней работать. И в новой конторе у меня до сих пор пригорает от этого культа безусловной иммутабельности. Гемора дофига добавляет.

 

[Степан Бабкин]

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

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

 

[Kittiket]

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

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