Pull to refresh
39
0
Артём @tmn4jq

Java developer

Send message
однако сегодня среда)

Завтра мы оба окажемся неправы :(
Или смогли.

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

Единственное, что раздражает, так это то, что вы в очередной раз надменно намекаете на то, что у вас этот опыт уже есть, а у меня – нет. И когда я вырасту, наберусь опыта, достигну вашего уровня, тогда я смогу узреть, о чем вы говорите. А говорите вы, как ни странно, об очевидном.
«Unit-тестирование важно, но не для всех проектов» — попробуете подискутировать?

Я не обладаю всеобъемлющим или каким-либо специфическим опытом, поэтому я бы перефразировал: «написание юнит (интеграционных) тестов зависит от специфики проекта».

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

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

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

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

Вы же говорите, что хоть сколько-то опытный человек будет в первую очередь нацелен на грамотное применение тестов – и с этим я абсолютно согласен. Я не согласен лишь с тем, что имея определенный опыт, вам запрещено дискутировать на тему важности самого тестирования.
«Не, я только Каштанку читал. Хочешь, за жопу укушу?» (с) Гоблин в переводе «Властелина Колец».

Не понимаю, зачем вы мне именно здесь рекомендуете художественную литературу ¯\_(ツ)_/¯ Как и утверждаете, что однажды у меня появится тот или иной опыт. Про применимость тестов есть отдельные посты, например ваш. И даже более объемные и фундаментальные. Но это не запрещает кому-то просто пообщаться на тему самих тестов и важности их применения. И это не говорит о том, что в беседе принимают участие только неопытные щенки, которые еще «в своем познании не настолько преисполнились...»
Во-первых, поиск и фильтрация резюме по ключевым словам легко может дать сбой и отсечь хорошего кандидата с релевантным опытом.

Вот этого момента я никогда не понимал. Одно дело поиск, но фильтрация входящих резюме… Как вы сказали, сейчас рынок IT – это рынок кандидата, и на этом фоне очень плохой идеей является фильтрация присланных резюме по ключевым словам.
У меня знакомый, вполне себе хороший специалист, однажды отправил так резюме и спустя 10 секунд получил отказ :) Просто, видимо, не указал достаточно ключевых слов, вместо этого чисто по-русски расписав свой опыт.
Это не наброс.
Каждый видит то, что хочет. Кто-то увидел себя, кто-то увидел свою противоположность. Кто-то видит просто наброс.
Это попытка описать процесс разработки глазами человека, который не понимает важности тестирования. Иными словами, суть поста как раз о его важности.

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

Так дискуссии пошли в комментариях, вы хотите сказать, что все отписавшиеся выше – девелоперы без опыта? Дискуссии созданы для того, чтобы делиться опытом.

Границы применимости юнит-тестов — вот предмет для дискуссий.

И да, и нет. Тесты сами по себе не несут ценности, важна их применимость – безусловно да. Но то, что обсуждать что-то другое «опытный девелопер» не будет – нет. Ну, либо вы слишком опытный, и большинству юзеров попросту не достичь вашего уровня.
А это плохо? Я согласен с утверждением, что тесты гарантируют, что ранее рабочие части системы не перестали работать после правок. Да, увеличенный объем необходимых для внесения правок – это цена такой гарантии. Суть в том, чтобы платить умеренную цену и не тратить на правки тестов времени больше, чем на правки кода, как по мне.
Заголовки двух предыдущих статей вы начинали со слов «Вредные советы». Не знаю, сколько читателей меня поддержат, но я прошу вас впредь поступать так же.

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

Потому что такими вещами не шутят. Это примерно то же самое, что пошутить «у меня папа умер».

Где вы заметили шутку в негативном плане? Я лишь привел термин ПДД, потому что это созвучно с TDD, BDD, и это подошло под общий настрой статьи. Не более того.

Так что, ваши обвинения в том, что я «придираюсь к словам» беспочвенны.

Ага, и сразу же:
А вам предлагаю исправить ошибку во фразе «тестировать, и тд», о которой я давно сообщил через Ctrl-Enter.

Действительно, вы придираетесь не к словам, а к отдельным символам. Вам спасибо, разумеется, за то, что сообщили об ошибке. Но не нужно меня уже в ТРЕТИЙ раз просить вместо «и тд» написать «и т.д.». Это идиотизм.

Я ради интереса посмотрел ваши комментарии к другим постам. Господи, да вы тот еще буквоед. Я бы заменил последнюю букву, но правила это запрещают. Вас действительно не смущает указывать авторам (а не просто комментаторам) на грамматические ошибки? Даже при условии, что сама статья вам вполне понятна, то есть не кишит ими? Вы не видите контента как будто, вам нужно просто до чего-нибудь докопаться. Показать, что вы умнее, самоутвердиться.

Для начала сходите и сами исправьте свой комментарий здесь, к примеру: habr.com/ru/company/selectel/blog/533412/#comment_22436494
«-тся» и «-ться» – это из какого класса? 5-6? Или же это начальная школа? Ах да, вы же уже не можете исправить свой комментарий, и все увидят, что вы тоже неграмотный.

И да, я сейчас перехожу черту и веду себя как идиот. Но вам же неприятно, верно? Так и сами себя так не ведите. Ежу же понятно, что вы хотели донести мысль, и я ее понял, да и вообще я сильно сомневаюсь, что вы не знаете этого правила. Скорее всего, допустили такую ошибку по невнимательности или утомленности. Уж правила-то вы знаете, это видно. Но докапываться до «тд» vs «т.д.» ТРИ раза (дважды в личном сообщении еще) – это просто бред.

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

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

И не нужно упоминать про свой почтенный возраст и неуважительное отношение. Было бы за что уважать.
Да весь ваш комментарий выше) Зачем вы мне пишете про соотношение зарплат разработчиков и тестировщиков? Статья не про это. Зачем пишете про ПДД? Статья и не про это тоже.

Лучше расскажите, какой у вас был опыт с написанием/сопровождением тестов или какие были проблемы от их отсутствия. Это будет по теме.
Потому я говорю, что код и юнит-тесты – часть одного целого. Если намеренно меняете логику, то обновите и тест, чтобы в будущем непреднамеренные изменения были отловлены.
Вы так пишете про свой возраст, как будто это на что-то влияет. Люди выстраивают свое мнение о ком-то базируясь не на сухом возрасте, а на знании дела и умении им делиться. Я не сомневаюсь, что знание дела у вас побольше моего, вы же как-никак на поколение старше, но вместо демонстрации этого знания вы просто придираетесь к конкретным словам без особого углубления в тему поста.
Просто изменения логики приложения с последующей коррекцией тестов и непреднамеренное ломание других частей системы – разные вещи.
Думаю, суть кроется в тонкостях понимания пользователем принципов ООП с точностью до наоборот:
Т.е. меняя что-то(пересчет курсов), я ожидаю что все кто его использовал поменяют поведение. Для этого и нужна ООП собственно.
У вас какое-то поверхностное отношение к тестам. Ну, либо поверхностное понимание причин, по которым они нужны.

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

Такие штуки должны случаться очень редко. А то забавно у вас получается – тест сломался, значит надо менять тест. Если у вас отвалились какие-то тесты, то вам надо править как раз код до тех пор, пока они не перестанут отваливаться. Про «просто кто-то не учел ваше изменение» – совсем смешно. Кто-то должен учитывать ваши изменения, чтобы код оставался рабочим? Или это вы должны изменять код так, чтобы ни у кого ничего не отвалилась?

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

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

Насчет киберпнка – вы сами-то играли? Я наиграл 16 часов и получаю удовольствие от игры. Лично встретил пока что один баг (вражеский солдат завис), но он меня не лишил удовольствия. Но это другое, думаю, там ситуация такая все-таки не из-за юнит тестов)
у т.е. у вас предположение что наличие юнит тестов понизит кол-во багов?

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

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

Вообще, я бы не стал отделять юнит-тесты от разработки. Это единое целое. Разработчик должен не просто писать код, ведь сам по себе код никому не нужен. Разработчик должен предоставить какой-то результат, и это единственное, что требуется. Причем код, который что-то делает, а что-то нет, результатом не является. Для того мы и пишем маленькие модульные тесты на свой код, чтобы удостовериться в том, что результатом нашей работы в принципе можно пользоваться.
Я определенно возьму некоторые ваши тезисы для следующих вредных советов. Про успокоительный эффект зеленых огоньков CI особенно понравилось. И правда, фигня все это! А вот красные огоньки ошибок на продакшене бодрят как следует!
На самом деле, я приветствую гневные комментарии к этому посту. При условии, что вы разобрались в вопросе и обоснованно доказываете мне обратное. Это значит, что вы понимаете важность тестирования, а пост, на самом деле, именно об этом. Да, это не хабр-формат, может, кто-то неправильно поймет. Однако, я нарочно сильно утрировал местами, чтобы лучше намекнуть на цель поста.
Согласен, это нечно необычное для хабра, и пишу я сюда редко. Я пишу такое у себя в блоге, и там я всегда делаю посты-разоблачения на свои вредные советы :)
Надеюсь, автор заметил по комментариям, что многие восприняли статью всерьез, или догадались об иронии не сразу.
Голосую за то, чтобы автор(ы) не применял(и) такой стиль изложения.

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

Не такое уж и дешевое — в среднем 80% от зарплаты программиста.

Я бы эти цифры оспорил, но не в том суть. Время тестировщика не дешевое, и переоценить вклад хорошего тестировщика в проект сложно. Это очевидно, что написано про дешевизну времени было ради шутки и соответствовало духу статьи. Опять же, если ты тестировщик и обижаешься на это – тебе бы отдохнуть слегка.

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

Книга «Сила воли. Как развить и укрепить» Келли Макгонигал. Сама книжка очень крутая, и там есть ссылки на эти самые исследования. Речь идет не о переключении контекста по приходу домой с работы, а про постоянное переключение между разными задачами в пределах рабочего дня.

Злая шутка получилась. Многие своей кровью и жизнью за ПДД заплатили. И продолжают платить.

При чем тут это? Похоже, что ты просто решил докопаться до конкретных предложений и даже слов, даже поверхностно не понимая суть всего поста…
Т.е. меняя что-то(пересчет курсов), я ожидаю что все кто его использовал поменяют поведение. Для этого и нужна ООП собственно.

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

Information

Rating
Does not participate
Location
Самара, Самарская обл., Россия
Date of birth
Registered
Activity