>Потихоньку осваиваю программирование. Добрался до Unit-тестов, и нихуя не понял, зачем они нужны. Пишется, что они нужны для проверки отдельных методов, как я понял, на корректную работоспособность. Например, метод складывает 1 и 1, и возвращает 2. И типа ты пишешь тест под этот метод, чтобы он проверил, что метод вернёт именно 2, правильно ли я понял? И если так, то вопрос - а нахуя писать тест, если можно запустить программу, и самому увидеть в ней, верные ли она выводит данные или нет? Я понимаю, что программы могут быть очень и очень большими, могут дорабатываться со временем и изменяться, и юнит-тесты нужны, чтобы проверить, что всё работает корректно. Но я не понимаю другого. Если метод изначально работает некорректно - ошибку ведь видно сразу, т.к. человек, пишущий программу, наверняка запускает её и проверяет работоспособность, и тогда человек эту ошибку сразу исправляет. Соответственно, если метод изначально написан верно, то что с ним может случится за долгое время эксплуатации программы? Если его не трогать, то он будет и дальше выводить корректные данные, а если этот метод потребуется переписать (под новые нужды новой версии программы) - то ведь при переписывании, программу, опять же, будут включать и смотреть, корректно ли она работает. И тут я возвращаюсь к своему вопросу - так зачем нужны юнит-тесты? Спрашиваю не ради троллинга, просто хочу понять, что я упускаю из виду.
>т.к. человек, пишущий программу, наверняка запускает её и проверяет работоспособность, и тогда человек эту ошибку сразу исправляет
код может быть переписан, дописан, логика методов сложная
может быть КРАЙНЕ НЕОЧЕВИДНО что там подразумевали лет 10-15 назад в каком-нибудь легаси, особенно когда придет другой человек в команду
так что это хоть какая-то гарантия что джут не сломает важный функционал
Спасибо. А как эти тесты вообще проводятся? Типа, запускается отдельный фреймворк, в него вставляется кусок кода из основного приложения и прогоняется? Или вся программа целиком копируется туда, и там уже как-то делится на изолированные части?
Так вот, если ты заранее напишешь юнит-тесты, то этой проблемы можно избежать и на этапе переделывания сервиса2 просто запустить тесты и посмотреть, ничего ли не сломалось. Тесты тебе покажут, где проблема и ты ее исправишь в зачатке, что очень удобно
Насчет того, как эти тесты проводятся, кури библиотеки для тестирования своего языка, гайдов полно
Спасибо за красочный пример, анонче, вот таких аналогий очень не хватает. А то написать про преимущество юнит-тестирования мы любим, а объяснить простыми словами, что это вообще за вещь и зачем она нужна - как-то не спешим.
В юнит и функциональных тестах есть смысл только на больших энтерпрайз приложения. В остальном случае это суходрочка и выебоны.
Научиться их писать довольно просто, а потом неделя практики и готово.
Есть ещё TDD, это когда сперва пишут требования к результатам, а потом сам функционал. Забавная, но специфическая хуйня.
Если изучаешь погроммирование, то попробуй канешн, но не увлекайся сильно, и учти, что если пишешь тесты и тебе за это не платит работодатель, то ты долбоёб. Лучше работу поищи или пет проект пиши.
> Добрался до Unit-тестов, и нихуя не понял, зачем они нужны
> Добрался до ентерпрайз-параши, нихуя не понял, зачем она нужна. Дрочи алгоритмы, прочую CS-муть и пиздуй на собес, бот. Понимание Unit-тестов придет только с опытом.
Если у тебя 1000 методов то ручками ты ничего не посмотришь.
Юнит тест должен проверять не только, что 1+1===2, но и кучу крайних случаев.
Типа что если вместо цифр придут строки?
Какое исключение кинешь и как его обработаешь?
Покормил зеленого
Тестирование вообще нужно не для проверки работоспособности, а для гарантии того, что в любой момент твое приложение выдает предсказуемый результат
Ну и чтобы не полагаться на мясную обезьяну - тестировщика
Почти любое ПО пишется кусками и постепенно развивается/меняется. Поэтому написать и забыть это утопия.
И методы бывают сложными, ошибки в которых могут быть неочевидными, т.е. в обычных условиях работают, а какие-то специфические данные и сразу хуяк. Проверять это руками ты заебешься, особенно перепроверять каждый раз.
И методов много. Например, у нас проект с финансовой залупой, и там чтобы сделать нужную штуку запускается около двадцати отдельных методов. В начале было всего пять или шесть, остальные добавились потом. Угадай как это заебись проверять руками.
А так когда у тебя нормальные тесты есть и они интегрированы с системой CI/CD то по сути после каждого коммита все важные части приложения могут быть автоматически протестированы на предмет того сломали ли что-то свежие изменения.
Маконнела прочитал?
>В юнит и функциональных тестах есть смысл только на больших энтерпрайз приложения. В остальном случае это суходрочка и выебоны.
Не соглашусь. По сути любое крупное (чисто по объему кода) или важное ПО нуждается в тестах, вопрос только как и что будет покрыто тестами. Покрывать всё - да, это боль. Но типа даже простенькие сервисы если там касается денег, уведомлений и прочего, то стрёмно без тестов.
7 лет в разработке, фуллстек 300к наносек, не знаю правил солид.
Пойду вздёрнусь штоле.
240к, не прочитал ни одной книги по кодингу, кек
Да и не выгодно. Через год команда уже больше правит постоянные баги, чем пилит новые фичи.
Пиздишь. Знаешь и применяешь, просто сформулировать не можешь. А если нет, то скорее всего говнокодишь люто
>Через год команда
>правит постоянные баги
> команда
Что же за команда долбоёбов такая?
Немного хуита. Все внешние сервисы мокаются и ты узнаешь, что обосралось прямо в продакшене. Но это и не твоя вина, а долбоеба, который свой сервис недотестировал или не умеет в версии, так что всё честно.
Это когда долбоеб-менеджер не выделяет времени на написание тестыюов. И на регресс тоже не всегда.
Кстати, сам ты долбоеб
Отвечу за него, формальные знания редко соответствуют качественному коду. Как и абсолютистское следование всяким практикам. Мне достался проект на джаве, там все хуесосы с сертификатами писали, спринг, паттерны-хуятерны, а там пизда: кривое, косое, бажит, опечатки в переменных, кривое наименование, орда копипасты на ровном месте (как блядь), зато ехала фабрика фабрики для построения фабрик и прочее ООП головного мозга.
Зависит, у нас проект такие где фичи всегда добавляются, но да темп запила новых фич совсем иной уже через год.
Такая, которой приходиться работать с парашными чужими апи, ебанутым хромом (который сам обновился и сломал фичу азаза или просто решил насрать на свои же стандарты), а также необходимосью пивотить реализацию отдельных фич на пяточке.
Учитывая что 40к веб програмистом не охота
Я об этом как раз. Фичи добавляются гораздо медленнее и меньше из за постоянных багов в старых фичах. На тестирование которых менеджер зажопил время.
Уже уволился оттуда, а все бомбит.
>Типа что если вместо цифр придут строки?
Питухонодебил не палится, лол. Пиши на нормальном языке, а не на динамической параше и такие косяки на этапе компиляции отлетят
Понятное дело, что нужно код писать так, чтобы даже ромка-попрыгун понял. И понятное дело, что в руках долбоеба все что угодно может стать говном. Но если ты берешься писать в ООП стиле, основные принципы знать стоило бы, даже если ты и не собираешься их использовать принципиально
Да-да, мой милый любитель бойлерплейта.
Слышу слышу.
>Сеньоры и прочие hr-менеджеры, есть ли предвзятость к людям с неоконченным высшим?
Про HR не скажу (у нас они только бумажки перекладывают и договариваются о собеседованиях), а нормальным разрабам похуй. У нас 60+ процентов без профильного диплома. У многих заочные дипломы или неоконченное.
> Преподы байки травят что без диплома никуда
У тебя не возникает очевидный вывод, что слушать старого пидора с конфликтом интересов в данном вопросе не стоит?
>Учитывая что 40к веб програмистом не охота
Таких почти не бывает. Ну серьезно. Если ты попадаешь ложкой в рот, то уже больше будет. Если не сразу так через год. У нас тут блядских WP разработчиков (верстка, базовый php и щепотка джаваскрипта) хантят на 150к лол. Вот в пятницу один ушел. У нас получал 100к, мы бы платили больше, но чувак что-то совсем не хотел развиваться по скилам. Только базовые проекты тянул. А тут хуяк и ему оффер на 150к за тоже самое.
АХАХАХХАХА. П-Р-О-В-Е-Р-Я-Е-Т. АХХАХАХАХАХАХАХААХА.
Хуярят непроверяя, лишь бы скинуть таск обратно QA.
По опыту могу сказать, что обычно если человек не совсем еблан, то он приходит к нормальному коду сам. Сначала ты ебашишь лапшу с копипастой ублюдочную, но потом понимаешь что в случае чего менять что-то больно и начинаешь дробить её на части. А потом ты узнаешь про ООП и понимаешь, что часть вещей отлично вынести в классы можно и так далее, и так далее. А если понимаиня нет зачем и нахуя всё это, то потом эти зомби-кодерки рождают этих мутантов, где формально все лучшие практики, а на выходе почему-то кал.
А мне вот интересно как он докатился до 1000 методов.
Ошибка может возникать очень редко. Тесты автоматически запускаются на серверах по много раз за день. Вероятность бага в релизе снижется.
Да, соглы. Ну тут вопрос скорее в том, в какой момент времени придет это понимание. Принципы закладывают зерно, а ты уже сам дальше действуешь. Обычно ты начинаешь что-то писать и анализируешь, как можно улучшить код. И вспоминаешь про то, что выучил и начинаешь понимать, зачем это так придумано. А потом через какое-то время начинаешь ебошить уже без размышлений.
чем тебе компайлтайм чэки помогут если параша прийдёт в рантайме? ку-ку, не все пишут бложеки, где всё в рамках одной системы работает
Тем, что ты в принципе не сможешь подключить модуль с чужим кодом и как петух на петухоне вызывать метод кококо Кукарек(инт а) пихая ему стринг г
Даже в том же голанге такое легко обработать, да и в питоне тоже можно разрулить типами и валидацией.
бинго, валидацией, а не полагаясь на манятипы
>>254027745
с чего ты взял что чужая хуйня подключается кодом азаза?
Чел, сейчас компиляция, литнтеры, статические валидаторы и прочая зумерская хуйню даже пёрнуть не даёт в код, не то что насрать.
Так в питоне настроенный mypy тоже не даст, код не пройдет проверки в CI.
Ты до сих пор думаешь, что проблема будет в исходниках основного проекта, а не в том, что дауны будут слать в него снаружи лол
Ну, так это проблемы даунов
Откуда у тебя дауны снаружи и как они засылают код к тебе?
Если бы, анончик, если бы. Когда проект пилят с разных сторон, или у тебя есть API, или ты юзаешь чужой API, то всё куда хуже. Особенно если с вами интегрируется какая-то залупа другой конторы, у которой сидят черви пидоры вместо разработчиков.
Данные из вне просто так попадают в методы? Да у тебя на этапе десериализации json вылетит ошибка если структура окажется другой.
расскажи этим червям пидорам ещё как джейсоны нормальные собирать, у нас были проекты вместо всякие ебаные стыды делались вместо нормальных джейсонов, потому что та сторона ниасилила
серьезно, вам походу ребята повезло пилить проекты без кривых апи, где rest api возвращает ошибки с кодом 200 OK или говорит success, когда параша сломалась, или когда они должны слать одно, но иной раз приходит другое и прочее-прочее-прочее, и в итоге у тебя вместо обычного кода на каждом шлюзе толстый слой говночеков и лишней валидации, в том числе по косвенным примерам, или ещё охуенее, когда у тебя висит система очередей чтобы перепроверять результаты, которые типа уже отработали раньше азаза, потому что платежный шлюз отвечает тебе что оплата обосралась, но ты знаешь, что нельзя фейл показывать конечному покупателю, ибо есть 60% вероятность, что оплата прошла, просто эти хуесосы слишком рано ответ ёбнули тебе (как нахуй такое возможно?), и надо потерпеть и запустить дополнительный запрос чтобы проверить в списке запросов статус хуйни пост-фактум и о ебать а оно на самом деле прошло азаза
И это не какие-то смузистартапы со студентами, это блядь финансы, энтерпрайз, бизнес нахуй, или ещё хуже - банкинг, здравоохранение и госпроекты азаза
>>254028060
Значит надо эскалировать проблему наверх, договариваться о формате. У вас ПМ и техлид за что деньги получают?
А причем тут кривые типы которые в языках со статической типизацией ты не сможешь разложить в структуру и обязан обработать эту ошибку в коде? То что ты работаешь в параше где бэк пишут идиоты на динамических языках это только твои проблемы.
Глиста высрал?
Это я программированием занимался
Сейчас монолиты вышли из моды, иди дроби на микросервисы.
не читай школьников сверху.
Дело в том что юнит тесты пишут не под отдельный метод а под целый модуль. И этот модуль может быть изменен в дальнейшем, например могут быть изменены используемые внтури типы. Но не логика модуля. Тесты позволяют после этих изменений убедится что все норм.
Короче ещё проще:
func()
{
T a,b;
return a+b;
}
Пишется тест под для func. А потом может потребуется поменять T. Тест позволит убедится что func по прежнему делает что надо.
какой же ты дебил
Потому что бывают методы, которые нельзя на глаз проверить, которые требуют входные данные или другие особенные вещи, а также их количество может быть больше одного, и ещё миллиард причин. Всё равно никто не пишет юнит-тесты, потому что считают себя самыми умными, а потом посреди ночи дебажат своё говно вместе с остальными командами, когда прилетел блокер с прода
Вот только так могу, это массив его надо раздробить
Это хип, какой нахрен массив?
Я ньюфаг ведь, не шарю. Хип знаю только хип хоп типа моргенштерн и гуф