>дебаг-мод
Что, простите?
>эти откровения крудо/вебмартышки
Ясно.
Понятно.
Вангую TDD-головного-мозга.
Студентик с лаба1 не понимает, что во всех проектах есть чужой код.
Он должен быть 100% покрыт.
>1) Вы фиксите чье-то легаси.
У тебя дислексия походу, братан.
О, а вот и диванные подъехали
>юнит-тесты
Это оксюморон, TDD-дурачки. assert 1+1==2 - все ваши юнит тесты, они просто ничего не тестируют. Вся сложность во целиком взаимодействии частей.
Грамотная и прозрачная архитектура важнее любых твоих тестов. Со 100% покрытыми тестами ты при изменении функционала больше половины времени будешь тратить на переписывание своих тестов, которые через две недели снова станут неактуальными. И если другой включит разок в неделю дебаг мог и исправит странный баг, то ты как макака будешь только и делать, что тесты переписывать. В идеальном пониленде, где тебе на перекрашивание кнопки дают полгода, может твое 100% покрытие и работает. И по итогу все равно в один прекрасный день прилетит тебе такой кейс, который нигде у тебя в кейсах не прописан и будешь ты также в своем лапшекоде с дебаг модом отлавливать еще более злой баг, который в нормальной архитектуре физически невозможен.
Код не может быть покрыт на 100%, это абстрактная цель, к которой нужно стремиться.
Юнит-тесты тестируют чистую логику. Во взаимодействии никогда нет никакой сложности, если у тебя нормальная архитектура и ты работаешь от интерфейсов.
Это как раз и значит, что у тебя говенные тесты и говенная архитектура, в которой все ломается от одного изменения. Если ты меняешь что-то в одной части и 10 тестов начинают фейлить, то либо ты поменял API компонента, на который завязаны 9 других, либо ты что-то сломал. Для этого кстати и нужны юнит тесты, чтобы локализовать свою поломку. 10 разных юнит-тестов не могут ломаться от изменения в одном файле, иначе они нихуя не юнит-тесты.
Не читай Дядю Боба, он поехавший долбоеб.
Кто такой дядя Боб?
Я тут новенький.
> Во взаимодействии никогда нет никакой сложности
Охуительные истории
Ничего там нет охуительного, просто это школьник.
Даже не студент.
>wat is goooggle?
Основная сложность - это всегда логика. Само взаимодействие по своей сути тривиально - ты берешь данные из одного компонента и передаешь их в другой, где тот их обрабатывает, следя своей логике. Сложным и нетестируемым оно становится только тогда, когда у тебя непродуманная архитектура, логика распихана где попало и взаимодействия происходят не через интерфейсы, а напрямую.
>эти откровения крудомартышки на каникулах
Мальчик, иди гуляй.
>ноунейм с сосача пиздит на дядю боба
Ты бы хоть привел чужие слова и аргументы, раз сам сформулировать ничего не можешь.
Долбоеб, придумай(хотя бы в теории) такой пример, где взаимодействия были бы основой сложной системы и где логики по минимуму/ее нельзя вынести отдельно по какой-то причине.
>взаимодействия были бы основой сложной системы
Нейросеть.
Теперь можешь идти гулять, каникулы же.
> Высеры говноюаней
>высру-ка я баззворд и обзову школьником, авось никто не заметит
Мальчик, давай я тебе объясню. Нейросеть - это набор математических алгоритмов. Работоспособность математического алгоритма нельзя на 100% протестировать в классическом ввод-вывод юнит тесте, ее можно только доказать. И когда ты вывел доказательство и уверен в работоспособности, ты начинаешь этот алгоритм реализовывать. При этом тестируются не ввод-вывод, как при работе с данными, а конкретные процессы внутри этого алгоритма. Твой баззворд не попал в тему, высри еще что-нибудь.
>нинужно врети ниработает
Ясно.
>Нейросеть - это
набор связей между нейронами.
Школьное образование совсем проебано.
Снова.
Заебали уже веб макаки. Отладка - это очень важный инструмент при работе со сложным софтом. Я пишу на крестах и работаю в компании, занимающейся видеонаблюдением. Не в РФ.
Так вот, товарищи. В таких сложных программах на миллионы строк кода просто "тестики написать" не вариант. Там пишутся целые тестовые утилиты, которые подключают DLL и позволяют подёргать функции инфтерфейса. Там используется массово отладка, разбор дампов/мегабайтов логов и прочая муть. Найти какой-то баг, пришедший из репорта без отладчика просто не реально.
Если вы никогда ничего сложнее /var/www/html/laravel-blog/tests не писали - это ваши проблемы.
Так вот, товарищи. В таких сложных программах на миллионы строк кода просто "тестики написать" не вариант. Там пишутся целые тестовые утилиты, которые подключают DLL и позволяют подёргать функции инфтерфейса. Там используется массово отладка, разбор дампов/мегабайтов логов и прочая муть. Найти какой-то баг, пришедший из репорта без отладчика просто не реально.
Если вы никогда ничего сложнее /var/www/html/laravel-blog/tests не писали - это ваши проблемы.
Очередной додик, который выучил баззворд, но при этом сам не написал ни одной строчки нейросети, максимум дергал Azure API. Обоссан.
>у меня есть программа на миллион строк кода, написанная хуй знает как и я дергаю интерфейс, подгружая 50 библиотек, если мне нужно сложить a и b, именно поэтому тесты не работают
Ты что сказать-то хотел?
>додик
>Обоссан
Школьники, школьники never change.
>Ты что сказать-то хотел?
Школьникам не понять.
>хых, ну нейрасеть эта типа там нейроны)) ну как в мозгу кароч прикинь) я на ютуби видево видел там нейрасеть ента училась в марево играть)) хых терминатар тупа) я кстате сам праграмист тоже магу нейросети писать)0)
>если мне нужно сложить a и b
Кто-то мутит нейросети, кто-то обрабатывает видео, TDD-дурачки все никак не могут уложить в голову что-то сложнее сложения двух чисел
assert 1+1==2
ТОЛЬКО 100% ПОКРЫТИЕ
Среди TDD-дурачков есть такая прослойка тех кто уже начал понемногу осознавать что его покормили говном, но еще не желающих перестать копротивляться из последних сил. И тогда они достают последний свой "весомый" аргумент - главное что при TDD-разработке мы достигаем хорошей архитектуры. Но что же такое "хорошая архитектура", спрашиваем мы у TDD-дурачка? - Это такая архитектура для которой удобно писать assert 1+1==2 тесты! - Отвечает TDD-дурачек. Финиш.
Эта неунимаемая боль индусской мартышки, чей код переходит в раздел неподдерживаемого легаси говна сразу после написания, но она все равно пытается кукарекать на TDD-господ гнилой демагогией, думая, что имеет малейшее представление о предмете обсуждения.
Вот этого пожалуй поддвачну. Вместо нормальной, максимально понятной и максимально очевидной архитектуры кода мартыханы стали надрачивать на тесты, и похуй что потом это читать нереально, зато они покрыли все тестами и типа задача сделана.
Этот школьник полностью перешел на кукареканье, уносите.
>эти проекции малолетнего вебдегенерата
Даже жаль тебя.
> это доведение до абсурда
Стопроцентный детектор неопытного студента.
Твой объебос как-то пизданул в своем бложике, что строгая типизация не нужна, потому что есть тесты. После этого эту мартышку читать - лишь время терять.
Таки годный бизнес-план.
И эти гои будут учить нас делать дела, ой-вей.
Он писал очень интересный пост с рассуждениями по теме, а тут приходит мочанерский ноунейм и говорит "не, анкл боб)) соре ты хуйню сказал яскозкал))". На, перечитай, а то может ты где-то в твиттере хуйни нахватался по цитаткам, а сам пост не читал, может заодно сумеешь аргументировать свой пиздежь и то, в чем ты не согласен, а не просто в лужу пердеть:
http://blog.cleancoder.com/uncle-bob/2017/01/13/TypesAndTests.html
И еще одна, откуда ты мог вырвать свою цитатку:
http://blog.cleancoder.com/uncle-bob/2016/05/01/TypeWars.html
>assert 1+1==2 - все ваши юнит тесты
Нет, это все твои юнит-тесты, потому что ты не умеешь в тестирование. Не проецируй.
На всякий случай напоминаю. Тестирование - карго культ. Целиком.
Двачую адеквата.
Uncle Bob, очевидно. Известный программист.
Проиграл с этого слабоумного.
Анон, ну все же понимают, что у байтоебов свой мир, имеющий мало общего с разработкой софта в целом. Никто не собирается забирать у тебя дебаггер, если ты пишешь на сишечке, разговор же о другом. (По крайней мере я надеюсь, что оп это имел в виду.)
Шел 2018 год, мартыханы все еще не могли осознать, чем строгая типизация отличается от статической. Иди лабы на паскале делай, дебил.
Ну покажи мне тогда нормальные юнит-тесты которые хоть что то тестируют.
>Uncle Bob, очевидно. Известный уебан.
подправил маньку
Скинул в личку, проверь.
Лучше ты покажи пример своих юнит тестов, которые что-то не тестируют и я тебе расскажу, как их сделать нормальными.
Два дебила - это сила.
Давайте я вам лучше хуй покажу.
Два дебила - это сила.
Не существует никаких байтоёбов. Это всё миф, навязанный макаками. Приведу цитату с известного места:
>Машина должна и будет служить людям, она не шлюха, чтобы люди исполняли её прихоти. Отсюда байтобляди (а так же сочувствующие им императивные пидорасы, надрачивающие на показатели System.currentTimeMillis() - start) - пиздолисы, которые опускаются до полного говноедства, лишь бы ублажить её регистры и микросхемы. Альфапрограммисты, как и положено альфам, если машина не выполняет положенных ей задач и требует пресмыкаться перед ней и ублажать её байтами, просто берут и за патчкорды, ебашат с вертушки по передней панели и списывают машину на мороз, купив взамен ту, которая не будет выёбываться и выполнит код в сроки и без выебонов, будь там хоть 1000% неоптимизированного оверхеда. И настоящего программиста не волнуют вопросы выдрачивания и быстродействия - он решает важную задачу из предметной области гораздо более сложной, чем низкоуровневое дрочево, и отвлекаться на всякую подзалупную хуету вроде осоьбеннойстей какой-то там архитектуры ему некомильфо.
Вот, как бы, то ж бо и воно. Вот и вся идеология. Аж читать противно.
Что забавно: рост производительности процессоров закончился, и теперь все постепенно начнут все больше и больше заморачиваться оптимизацией. Особенно когда жирные времена в айти пройдут, и придется экономить на инфраструктуре (ускорение в 2 раза в масштабах какого-нибудь фейсбука - миллиарды экономии в год).
Всегда пытался понять, почему все так хотят этот дебаггер. Мне всегда в консоль напечатать хватало. Теперь понятно.
Напоминание всем малолеткам итт: единственные тесты которые вы обязаны писать - acceptance tests (https://en.wikipedia.org/wiki/Acceptance_testing).
>http://blog.cleancoder.com/uncle-bob/2017/01/13/TypesAndTests.html
>эти тонны ебаной воды, чтобы заявить, что
>So, no, type systems do not decrease the testing load. Not even the tiniest bit.
И кто он после этого, как не долбоеб?
Просто ты ебаный фанатик и будешь жрать любое говно от любимого фюрерка. Даже такое:
>You don’t need static type checking if you have 100% unit test coverage.
Сосни-ка хуйца. Еще я дословно унылые высеры поехавших пиздюков не запоминал.
>http://blog.cleancoder.com/uncle-bob/2017/01/13/TypesAndTests.html
>эти тонны ебаной воды, чтобы заявить, что
>So, no, type systems do not decrease the testing load. Not even the tiniest bit.
И кто он после этого, как не долбоеб?
Просто ты ебаный фанатик и будешь жрать любое говно от любимого фюрерка. Даже такое:
>You don’t need static type checking if you have 100% unit test coverage.
Сосни-ка хуйца. Еще я дословно унылые высеры поехавших пиздюков не запоминал.
Годная паста, схоронил.
Да никто и не переставал заморачиваться оптимизацией как бы. Алсо, закончился рост производительности ядер - и началось увеличиваться их количество, что фактически выкинуло байтоебов на свалку истории, где им и место.
>И кто он после этого, как не долбоеб?
Успешный и авторитетный разработчик, разжевывающий для таких как ты очевидные вещи, не?
>You don’t need static type checking if you have 100% unit test coverage.
Довольно очевидное утверждение для любого, кто хоть что-то смыслит в системах типов.
>Еще я дословно унылые высеры поехавших пиздюков не запоминал.
Ржу в голос. Ты не отличаешь статическую типизацию от сильной. Ты просто конченый дегенерат, анон. Просто картина маслом: не разбирающийся в типизации кретин учит дядю боба писать тесты, лол.
>Довольно очевидное утверждение для любого, кто хоть что-то смыслит в системах типов.
Ай, питуханя, похудей. Это уже перебор.
>Ты не отличаешь статическую типизацию от сильной
Ты я смотрю еще и дислексией страдаешь, купно со слабоумием. Бедняга.
>мам, ну скажи что он троллит))00)
>Годная паста, схоронил.
Макака ещё и ньюфаг? :з
Ну так расскажи, зачем, по твоему мнению, нужна типизация, и какие она выполняет задачи. По-моему все вполне логично: если у тебя есть возможность проверить работу кода за секунду, прогнав юнит-тест, то и ты так узнаешь, компилируется он или нет, а если нет, то в чем именно ошибка. Без всяких типов.
>зачем, по твоему мнению, нужна типизация, и какие она выполняет задачи
Для формального описания решения задачи. Что бы тайпчекер мог верифицировать, что ты, скажем бананы не складываешь с серной кислотой. Целиком исключая целые категории ошибок.
Дополнительный бонус - читабельность.
>По-моему: давайте наговнякаем хуевый тайпчекер на тестах!
Ебаный дебил. Признавайся, обезъяна, ты из уеб-мирка? Скриптопидоры просто не могут не переизобретать квадратных колес. При этом кукарекая изо всех петушиных сил, что колеса не нужны, ведь сгущ и в пердаке прекрасно переносится.
Какие еще есть норм лекторы, которые затирают про TDD? Дядю боба мне нравилось слушать, но он все время говорит одно и то же, после пяти выступлений уже наизусть знаешь все его тезисы и аргументы.
Но тесты и так описывают твою задачу формальным языком, при этом фокусируясь не на деталях имплементации(какой тип с каким ты должен складывать), а на результате(какое значение вернет функция, если ее вызвать с данными параметрами). Читабельность - это вопрос привычки.
>По-моему: давайте наговнякаем хуевый тайпчекер на тестах!
Никто не предлагает чекать типы в тестах или вообще их чекать, если уж на то пошло. В динамических языках все работает от интерфейса. Тебе все равно, какой с каким тип ты складываешь, до тех пор, пока твой объект поддерживает интерфейс сложения.
FS@UR Давай на связь выходи. Есть вопрос на миллион н-тел. Многолетний ты шардоаутист.
>Но тесты и так описывают твою задачу формальным языком, при этом фокусируясь не на деталях
Смотри, обезъяна, когда я на типах записываю. что a + b = b + a, для всех a и б принадлежащих мн-ву целых чисел, ты пидарисишь тест для каждой возможной комбинации а и б. Точнее ты этого не делаешь, а только чекаешь, что 0 + 0 = 0 + 0 и удвлетворенно вскукарекнув "100% покрытие тестами, ко-ко!" пускаешь все на прод, подсознательно готовя сраку под шипастые дилды, которые обязательно полетят, потому что 1 + 0 ты не проверил.
>Никто не предлагает чекать типы в тестах или вообще их чекать
Ты не обучаемый. Пидарась тесты в динамопитушне, так от тебя хоть вреда будет минимум.
Если у меня есть требование "написать функцию, которая принимает два аргумента 0 и 0 и возвращает 0", то я пишу тест, пишу функцию, отправляю на прод. Если вдруг мне понадобится расширить эту функцию, чтобы она принимала 1 и 0 и возвращала что-то другое, то я пишу еще один тест. Если я жду в эту функцию не только integer, но еще и float, и это как-то влияет на конечный результат, то я отражу это в тесте. И так далее.
Суть твоего вскукарека непонятна. Ты не доверяешь языку без типов, что +(1, 1) возвращает 2? Дай конкретный юзкейс, где без проверки типов и полным тестовым покрытием ты получаешь какой-то другой результат, чем с проверкой типов.
>Ты не доверяешь языку без типов, что +(1, 1) возвращает 2?
Надо быть совсем отбитым дебилом чтобы доверять жс-говну.
>Дай конкретный юзкейс
Нюфаня, please.
Понятно, ты просто шизик.
Понятно, ты просто веб-мартышка.
Это как червь-пидор, только хуже.
Мартышка без аргументов слилась в школоилитизм, ведь если спросить мартышку по делу, чем практически отличается веб от любого IO приложения с гуем, мариышка ответить не сможет.
>эти сорта крудоговна
Ясно.
>мартышка нахваталась хуйни где попало и считает, что если прилодение поддерживает круд-интерфейс, то оно по умолчанию недостаточно сложное и недостаточно илитное
>"написать функцию, которая принимает два аргумента 0 и 0 и возвращает 0"
Блядь ты реальне ебанутый, пыщь-пыщь. Требование было написать функцию (+), которая гарантирует, что инвариант a + b = b + a всегда держится для любых а и б принадлежащих мн-ву целых чисел.
Ты как истый ебанат на подсосе старого пиздобола всерьез предлагаешь писать |M|^2 тестов. Ну дерзай хуле. Чтобы покрыть 32-х битный беззнаковый инт тебе понадобиться всего лишь ~10^19 тестов
>Дай конкретный юзкейс, где без проверки типов и полным тестовым покрытием ты получаешь какой-то другой результат, чем с проверкой типов
Как напишешь тесты на инт - приходи, я тебе 64битный инт подкину. А задно вычитание с умножением и делением.
Давай, признавайся, ты же веб макака?
>сложное
А ручонки-то дрожат.
Как же ты ловко сманеврировал от обсуждения типов и тестов к обсуждению алгоритму сложения. Или не ловко, может ты просто нихуя не понимаешь, о чем речь, но спиздануть хочется. Давай по пунктам:
1) Все, что делает типизация - это накладывает ограничения на код программы. Запись int a, b означает только то, что переменные a и b могут принимать ограниченное множество значений. Это никак не связано с тем, что ты можешь вычесть/сложить/умножить a и b. Вообще никак. Запись +(int a, int b) накладывает ограничение на интерфейс функции. Она не гарантирует, что результат сложения будет правильным или что сложение вообще произойдет. Она просто говорит "если ты вызовешь +(str a, int b), то конпелятор выкинет ошибку".
2) Типизация - это низкоуровневая и очень базовая документация. Когда ты объявляешь тип, ты говоришь человеку, который читает код "не вызывай функцию с другим типом, иначе нихуя не сработает". Но юнит-тесты - это точно такая же базовая документация, только более подробная. Когда кто-то читает тест, он видит "ага, функцию можно вызывать так, так и так, при этом будет возвращаться вот такой результат". Это на его совести - ознакомиться с интерфейсом функции и валидными параметрами. В обоих случаях ограничение накладывается программистом, а не какой-то конпеляторной магией. И возникает вопрос: а зачем нам накладывать два одинаковых ограничения, и в тестах, и в самом коде?
3) Ты путаешь реализацию алгоритма и работу с данными. Именно об этом я писал в этом посте Алгоритмы не тестируются через ввод-вывод всех параметров, они доказываются. Ты придумываешь алгоритм сложения, доказываешь, что в этом алгоритме a + b == a + b для всех чисел, и пишешь функцию +(a, b), которая реализует данный алгоритм. Юнит-тест для этой функции должен тестировать сам алгоритм, то есть его внутреннюю реализацию, а не сложение всех возможных значений int.
Давай, признавайся, ты же студентик?
>Типизация - это низкоуровневая и очень базовая документация.
Просто признайся, что ты ничего интереснее системы типов жабы не видел.
Ну-ка, а какая еще есть "интересная" типизация? Чекать null на каждый пердеж в свифте?
Блять, я так и думал, что использование арифметики как примера зациклит твой мозжечек.
Ну тебя, деревенского дегенерата, нахуй. Меня доебало разжевывать по третьему разу. Ебись ты со своими юниттестами и шипастыми дилдами в рантайме, а я продолжу пользовать тайпчекер компилятора.
Про завтипы, или System F ты и не слыхивал, похоже.
Ах да, из сострадания к наследственным дебилам, держи - https://en.wikipedia.org/wiki/Type_theory
Вдруг поймешь чего, поумнеешь.
Даун так и не понял, зачем у него в языке типы и какую функцию они выполняют, но зато высрал ссылку на википедию, которую сам не читал.
Ками, але.
>зачем нам накладывать два одинаковых ограничения, и в тестах, и в самом коде?
Он начинает что-то подозревать.
Для затравки раскури лямбда-куб Барендрегта. Когда наступит просветление, приходи за следующей порцией.
Вебмакака закукарекала
Если ты пытаешься так подъебать, что тесты не нужны, если есть типизация, то у тебя не получилось. В тестах ты описываешь случаи использования своего компонента, которые, так уж получается, одновременно служат еще и ограничениями этого компонента. В типах ты описываешь только ограничения и ничего больше. Тесты ты будешь писать в любом случае, с любой типизацией, так что их исключить ради типов нельзя. А вот типы ради тестов - вполне.
Мальчик, дрочи лямбды в другом месте, тут разговаривают на совершенно другую тему.
Тогда, уточни вопрос.
>Тесты ты будешь писать в любом случае
Никогда не писал. С чего бы это вдруг? Доказывай, давай, своё утверждение.
Хорошо, специально для тебя переделаю:
>тесты ты будешь писать в любом случае, если тебе нужен поддерживаемый код, который легко рефакторить и расширять
> >Тесты ты будешь писать в любом случае
> Никогда не писал.
На этом моменте этого говнокодера следует обоссать, смешать с говном, закопать и насрать на могилку.
Шаблоны рвуться больно. Я так понимаю, ты - любитель корпоративных хороводов и карго-культов.
Это такое доказательство?
>дебаг-мод
Он как бэ и нужон только для подстраховки.
> Вы игнорируете юнит-тесты
Тоже не очень то нужон.
Но ведь шаблон - это как раз макака, которая считает, что уж ей-то тесты точно не нужны, она слишком умная и времени слишком мало и вообще карго-культ(на что?). Таких как ты миллионы, а ответственного человека, который коммитит только проверенный и поддерживаемый код(== протестированный), днем с огнем не сыщешь.
>на что?
На иллюзию корректности.
>код(== протестированный)
>считает, что промытая карго-маня кто-то, а не он
Бля не все скопировал, но понятно короче.
Спорить с промытыми TDD-маньками невозможно, т.к. у них это просто берется за аксиому что
>проверенный и поддерживаемый код == протестированный
это все равно что веруну доказывать что бога нет.
1) Как ты рефакторишь существующий код без тестов?
2) Как ты обновляешь существующий код без тестов?
3) Как ты вообще знаешь, что твой код работает, если ты его не тестируешь?
Расскажи, какой магический способ ты открыл, что тебе не нужно писать тесты и при этом ты имеешь поддерживаемый код?
Предвосхищая твой кукарек "ну ыыы у меня кароч архитекутра красивая и кароч код тоже красивый мама сказала))) зачем мне тысты енти))" смоделирую очень частую ситуацию: ты обновляешь стороннюю либу в проекте до последней версии. Эта версия вводит несовместимые изменения в API нужной тебе функции, которая используется по всему проекту. Как ты собираешься отлавливать все ошибки, возникшие из-за этого?
Версия с тестами:
1) Прогоняешь все тесты
2) Фиксишь каждый ред дот
3) Отправляешь в продакшен и идешь спать
Версия без тестов:
1) Ну бля пытаюсь запустить проект, но он не конпелируется, фикшу ошибки копелятора
2) Ну бля он теперь не запускается, фикшу выкидываемые ошибки
3) Ну бля теперь надо вручную прогонять API всех компонентов, где как я примерно почувствовал, используется эта функция и смотреть на ошибки
4) Вроде все прогнал, теперь тоже вручную смотрю компоненты, где используются те пофикшенные компоненты и фикшу остальные ошибки
5) Ну наконец-то, в три часа ночи можно отправить в продакшен
6) Утром меня ебут в жопу за пропущенный баг из-за которого упало три сервера
7) Еще три дня отлавливаю и правлю все остальные баги, на которые натыкаются юзеры/QA
8) ТЕСТЫ НИНУЖНЫ КОКОКОКОК
Не пишущий тестов и продакшн кода говнокодер, плз.
TDD макаки просто не исправимы.
Использование дебагера не означает отказ от тестов. Отказ от TDD не означает отказ от тестов.
А этот ваш макакинг что 100% покрытие только в TDD - хуйня. Нет у вас 100% покрытия. Вы всё равно не проверяете все возможные состояния системы. На каждую функцию есть хотя бы 1 ассерт - не значит что вы 100% покрыли код тестами.
А тесты нужны не для того, чтобы проверить работает ли код, а для того чтобы менять рабочий код без страха испортить то, что уже работает. Прохождение тестов не может доказать правильную работу коду, один из принципов тестирования.
PS: Ничего против TDD не имею, просто руби-поебота со своей бездарностью просто вызывает отвращение.
Никто не говорит про 100% покрытие, это абстрактная цель, но факт в том, что TDD дает тебе возможность эффективнее покрыть в несколько раз больше кода, чем любая другая практика.
>А тесты нужны не для того, чтобы проверить работает ли код, а для того чтобы менять рабочий код без страха
Они нужны и для того, и для этого.
>Прохождение тестов не может доказать правильную работу коду, один из принципов тестирования.
Пик и полная статья пророка TDD дяди боба по этому поводу: http://blog.cleancoder.com/uncle-bob/2016/06/10/MutationTesting.html
Ну, видимо да, но тебе тут виднее.
>когда я на типах записываю. что a + b = b + a
Никогда.
>ко-ко-ко а у вас в науке - эксперименты ничего не доказывают
Блядь какой же он дебил.
https://en.wikipedia.org/wiki/Robert_C._Martin
Ну так и есть, ни образования, ни опыта. Мартышки вы белены объелись?
Какое отношение лямбда-куб имеет к тестированию промышленного кода? Правильно, на данный момент никакого.
Систем ф имеет к тезису того анона о том, что моделировать предметную область типами - плохая идея? Если ты писал что-то крупнее факториала на систем ф, то ты это и так знаешь, кстати.
Завтипы к разработке софта вообще отношения на сегодня не имеют.
Внезапно, двачую. Мне больно это признавать, но в этом споре адепт динамикодрисни действительно дал пососать малолетним долбоебам, нахватавшимся УМНЫХ))0) слов на википедии, но смутно представляющим, как все это соотносится с практикой.
Хорошая цитата, кстати.
>если бога нет то кто тогда создал весь мир?
>ты думаешь если подкинуть коробку с деталями от часов то они сами случайным образом соберутся обратно в часы?
>если бога нет то почему я не могу воровать/убивать/ебать гусей прямо сейчас?
Давай конкретный пример когда тесты тебе реально помогли.
Допустим у тебя есть либа которая как-то там обрабатывает юникод и ее меняют так что теперь Ё и ЙО одно и тоже или еще какой нибудь нелепый юникодовый опердень. И у тебя есть какие нибудь хитрожопые пользователи Ебобо и Йобобо и теперь будут коллизия. Но ты не можешь эту хуйни предвидеть блядь заранее и никак не можешь "протестировать" миллионы возможных корнер-кейсов. Это вообще вне твоих физических возможностей. Так что тесты и тут соснули.
Я уж не говорю что assert 1+1==2 ебантяи просто мокают все свои зависимости и на деле их тесты не тестируют ВООБЩЕ НИХУЯ.
>этот пик
Софизм просто соточка.
>Никто не говорит про 100% покрытие
Макаки на дваче говорят. Этот тред создала макака, так считающая.
>эффективнее покрыть в несколько раз больше кода, чем любая другая практика.
Что не есть хорошо. Львиная доля тестов не ломается никогда. То есть совсем. Их как написали один раз, так они и есть. Автоматические тесты должны защищать код от твоих макачьих рук, а если они всегда проходят ибо тестят внешне очевидные вещи. Это не очень хорошо. Кому нужно увеличение числа тестов, за счёт понижения их качества?
Автоматизировать необходимо часто повторяющиеся процессы. Я вообще сторонник того, чтобы в крупных проектах тесты писали не программисты, а QA. Пусть автоматизируют себе тестирование того, что заебет руками тестить. В данном случае TDD мне больше напоминает телевидение. То есть многие передачи в интернете бы никто не искал, а смотрят потому что ИДУТ В ЭФИРЕ. Многие тесты бы никто и не додумался писать, если бы не TDD.
А Боба своего мне не пость. Да, он хороший программист и всё такое. Но его личный опыт не может отвечать за всё сообщество.
http://david.heinemeierhansson.com/2014/tdd-is-dead-long-live-testing.html
Вот тебе автор RoR, ещё раньше Боба писал. Про его же фрэймворк. На его фреймворке Боб себе бложик писал, вряд ли ты скажешь что фигура менее значимая.
Тебе чего-то дохуя хэйта влепили.
Это мой ответ.
Это я.
>Давай конкретный пример когда тесты тебе реально помогли.
Тесты мне помогают каждый день, прямо как Иисус. Я не боюсь поправить баг, не боюсь добавить новый функционал, не боюсь зарефакторить функцию, потому что знаю, что у меня есть тесты, которые сразу покажут, если я обосрался. Я не боюсь работать с кодом и улучшать его. Без тестов это невозможно, отсюда и мемы говнокодеров про "работает - не трожь".
>Но ты не можешь эту хуйни предвидеть блядь заранее и никак не можешь "протестировать" миллионы возможных корнер-кейсов
Это часть процесса разработки. Ты не можешь предвидеть все и никакая практика тебе не позволит этого сделать. TDD гарантирует только то, что те требования, по которым ты написал систему, выполняются. Требования будут все время добавляться, изменяться, но до тех пор, пока тесты проходят, ты знаешь, что система работает согласно этим требованиям. И старым, и новым.
>ебантяи просто мокают все свои зависимости
Любой нормальный TDD-er тебе скажет, что моки он использует очень редко. Если у тебя дохуя моков обычных компонентов, то это следствие хуевой архитектуры системы.
>Кому нужно увеличение числа тестов, за счёт понижения их качества?
Каким образом увеличение числа тестов связано с их качеством? Какие тесты ты можешь выкинуть, для каких компонентов? Для тех, которые никогда не будут меняться? А откуда ты знаешь, какие будут меняться, а какие нет? Ты экстрасенс?
>Я вообще сторонник того, чтобы в крупных проектах тесты писали не программисты, а QA
QA должны искать баги, а не тестировать хуйню по мануалу как роботы. QA никогда не сможет протестировать снаружи все корнер-кейсы для всех компонентов, который может протестировать программист. В конце-концов, ответственность за работу своего кода лежит только на программисте, а не на левых дядях.
Я могу тебе постить Кента Бека, Мартина Фаулера и кучу других значимых личностей, но мы обсуждаем не их личности, а конкретную практику TDD и взгляды на нее. Пост я читал, разумеется, как читал и кучу дебатов, последовавших за ним, но ни один не убедил меня перейти обратно на BDD.
>Давай конкретный пример когда тесты тебе реально помогли.
Лол, нувыпонели.
Написал
> assert 1+1 == 2
убедился что
> 1+1 == 2
День прошел не зря
>Тесты мне помогают каждый день...
Птентованный TDD-аутотренинг от Бобика буллшит-коуча.
>TDD гарантирует...
Чего-чего оно гарантирует? Главное верить? У вас там секта?
>Какое отношение лямбда-куб имеет к тестированию промышленного кода? Правильно, на данный момент никакого.
А должно?
Ну смотри, я использую TDD каждый день, а ты кукарекаешь на мочане и думаешь, что юнит-тест - это assert 1+1 == 2. У кого больше экспертизы по этому вопросу?
>Тесты мне помогают каждый день, прямо как Иисус
Ты ж юродивый нахуй
>думаешь, что юнит-тест - это assert 1+1 == 2
На просьбы доказать обратною юродивые стыдливо отводят глаза.
>я использую TDD каждый день
Сочуствую.
>У кого больше экспертизы по этому вопросу?
Ты себя ОСОЗНАЛ экспертом? Офигеть теперь. Сочуствую.
Зачем ты споришь о вещах, в которых не разбираешься? Законченная laba1.cpp еще не делает тебя разработчиком, а процитированный гринтекст и вовсе выдает в тебе либо толстого тролля, либо сказочного долбоеба.
Перечитай цепочку постов, в которую я отвечал. Если же ты спрашиваешь вообще - в идеальном мире наверное должно, в идеальном мире весь код должен писаться с использованием инструментов формальной верификации. Вот построит Маск киберпанковый коммунизм на Марсе - там все опердени будут на коке, инфа 100%, я гарантирую это.
Опять же, со стороны я сторонник статической типизации, если что это выглядит как разговор взрослого дяди с малолетними битардами. Какие-то бессодержательные ужимки и кривляния в ответ на разумные посты. Это печально.
Во-первых, этот assert тестирует уже встроенную функцию языка, что бессмысленно. Во-вторых, он не проверяет, что эта функция(оператор) реализует операцию сложения, а только то, что если ты вызываешь +(1, 1), то результат будет 2. Если это и пример юнит-теста, то только плохого.
Отец в треде все в джуниоры. Правда, может на какого нибудь ждуниора ты бы произвел неизгладимое впечатление и он бы смотрел тебе в рот не отрываясь. Но хотелось бы все таки каких то фактов.
Ебать ты дебик, попробуй тред почитать/мозг включить
>Перечитай цепочку постов, в которую я отвечал
Один аноан спросил: "какая еще есть "интересная" типизация?", я ему посоветовал начать с лямбда-куба. И всё. При чём здесь "тестирование промышленного кода"?
>инструментов формальной верификации
Но тестирование для этого совершненно не годится.
Я тебе обосновал, почему этот тест ничего не тестирует. Теперь покажи мне, в каком TDD проекты ты его нашел и почему считаешь, что он является примером юнит-теста или иди нахуй.
Ну так вопрос того анона был в контексте разговора о тестировании и типизации. Один залетный предложил с помощью системы типов доказывать коммутативность оператора сложения, на что ТДД-анон ему справедливо возразил, мол такие вещи (корректность алгоритмов) мы, простые инженеры, доказываем на бумажке с помощью математики, а затем уже с помощью тестов повышаем уверенность в том, что наша реализация соответствует спецификации с доказанными свойствами. В ответ на это другой анон (ты, я так понимаю), предложил ему посмотреть на более интересные чем в джаве системы типов (речь, очевидно, шла о завтипах, поскольку относительно проблемы доказательства коммутативности сложения степень интересности джавы и систем ф одинакова). Посмотреть-то конечно можно, но в промышленной разработке за исключением специфических случаев, которыми можно пренебречь завтипов нет и не предвидится, а потому и предложение это не вполне релевантно той нити, в которой оно было озвучено. Надеюсь, теперь все прояснилось.
А небо голубое, а вода мокрая, а аллах велик. Привет.
>Давай, признавайся, ты же студентик?
Тебе бы самому не мешало бы подучиться в хорошем месте. Типизация - это способ доказывать теоремы.
И какие у тебя проблемы с этим тестом?
Его полная бесполезность.
>должен быть 100% покрыт
может еще заказчика попросишь на 100% знать чего он хочет
>должен быть 100% покрыт.
анус себе разве что покроешь когда надо будет делать рефактор своего тормозящего говна которое от любого чиха сломает юнит тест который тестировал тормозящую хуету
Очень мало теорем и очень большими усилиями, ага. Сам-то где учишься?
Закончил учиться больше 10 лет назад.
>Очень мало теорем
Ровно столько, сколько программ компилирующихся.
>Версия с тестами:
>1) Ну бля пытаюсь запустить проект, но он не конпелируется, фикшу ошибки копелятора
>2) Ну бля он теперь не запускается, фикшу выкидываемые ошибки
>3) Прогоняешь все тесты
>4) Фиксишь каждый ред дот
>5) Ну наконец-то, в два часа ночи можно отправить в продакшен
>6) Утром меня ебут в жопу за пропущенный баг в не покрытом тестами месте из-за которого упало три сервера
>7) Еще три дня отлавливаю и правлю все остальные баги, на которые натыкаются юзеры/QA и переделываю тесты.
>9) TDD рулит!
Пофиксил тебя, не благодари.
>Закончил учиться больше 10 лет назад.
Так где закончил-то? Расскажи, не стесняйся.
>Ровно столько, сколько программ компилирующихся.
Капитан Очевидность открывает Америку, картина маслом.
Не искушай, Анон. Прямо сплю и вижу как-бы рассказать, где учился, в какой стране живу и сколько зарабатываю.
Почему у убежденных тестоблядей такая проблема предоставить хоть какой то пруф что их хуита работает? Ведь они каждый день хуярят свои тесты и могли бы легко вспомнить пример вот я сделал то-то и то-то и благодаря тесту не допустил тут ошибку. Если только их хуита работает.
Каким образом этот тест вдруг стал бесполезным? Может ты путаешь "бесполезный" с "простой"? Он тестирует:
1) Инициализацию класса Portfolio
2) Публичный метод add у объектов этого класса
3) Публичный метод value у объектов этого класса
Или ты думаешь, что если там внутри кода на две строчки, то его не нужно тестировать, он слишком простой? Любой код начинается с одной строчки и растет со временем, сколько строчек кода нужно написать прежде чем макака с сосача сочтет его test-worthy и побежит задним числом тестировать и вспоминать все, что написала до этого?
TDD подразумевает, что у тебя есть тестовое покрытие, которому ты можешь доверять. Если весь такой проект написан через нормальное TDD, то у тебя не будет "пропущенных багов" из-за обновления либы.
Тесты - это пруф, что твой код работает. Без тестов ты можешь это проверить только в консоли. Но нахуя мне писать в консоли, если я могу написать этот же тестовый код в отдельном файле и он останется со мной навсегда? "Зачем мне тестировать, там же элементарный код" - см. мой первый ответ в этом посте.
>Тесты - это пруф, что твой код работает.
Тесты - это пруф, что твой код проходит тесты.
>140 постов
>никто не упомянул единственно верное, property based тестирование, служащее не только проверкой, но и инструментом анализа свойств функций
/зк, что с тобой не так?
^_^
>никто не упомянул единственно верное, property based тестирование, служащее не только проверкой, но и инструментом анализа свойств функций
/зк, что с тобой не так?
^_^
Пруфы-то где, Мань?
Или не проходит. И тут нужно размышлять что нужно "чинить" - тест или изменившийся код?
Вишенкой нужно добавить, что бобосодомиты отвергают комменты как великую ересь.
> И тут нужно размышлять что нужно "чинить" - тест или изменившийся код?
Обычно бывает так, что возникает проблема в продакшене из-за какого-то хитрого сочетания состояния и входных данных, и ТДД культисты так же ныряют в отладчик с головой чтобы понять что вообще происходит. И тесты тут никак не помогают.
>какого-то хитрого сочетания состояния и входных данных
Ох, не напоминай.
>property based тестирование
Надеяться на то что случайно сгенерируются особые случаи которые могут быть 1 из 10000...00000? Ну хуй знает, как-то это попахивает манямирком.
Сейчас придумали уже более лучшее колдунство - куколдное конкольное(?) тестирование. Там уже типа перебор идет с учетом структуры программы.
assert 1+1 == 2 тестирует
1) что у меня есть 1 и я могу вызвать 1
2) что на 1 определен оператор +
3) что я могу сравнивать числа
4) что в конце концов 1+1 == 2
так та
О, новый базворд которым я буду выебываться на собесе.
>TDD подразумевает, что у тебя есть тестовое покрытие, которому ты можешь доверять.
Тесты не могут покрыть всю ООФ и ОДЗф.
Базворд это ТДД. А это практически математика.
У меня такое чувство, что ты теперь споришь ради спора, когда аргументов уже не осталось. Опять вернулся к "тесты ничиво не доказывают, а если ты сравниваешь их с научным методом и экспериментами то это софизм яскозал!!".
Зачем тебе покрывать всю область значений? Про типизацию мы уже говорили, но и в ней можно сказать "но у меня же функция работает только с числами от 0 до 10, зачем мне int, хочу новый тип чтобы он уж точно-точно ограничивал". Есть момент, когда ограничения того не стоят, в динамических языках он наступает раньше, в статических - позже.
В динамических языках нет ограничений, все является дилдами, даже Небо, даже Аллах!
В динамических все ограничивается интерфейсами, только они не объявляны явно, а являются договоренностью.
>сравниваешь их с научным методом и экспериментами
Так делают только образованные телевизором/ютубчиком, не делай так, не опускайся до такого, анон.
Ну я то же самое сказал
На практике, чем отличается тест от эксперимента?
Ох ну нет, так не пойдет. Ты заявил их похожесть, вот и аргументируй.
>Зачем тебе покрывать всю область значений?
Может быть баг в реализации и при каких-то параметрах приложение распидорасит, что-то вроде бага Pentium FDIV.
А может метеорит на сервную упадет и все распидорасит.
Что из этого уникально для эксперимента и не присутствует в юнит-тестах?
> только говнокодеры используют дебаг-мод.
орнул
>Вы игнорируете юнит-тесты и ваши юниты слишком большие чтобы вы могли их полностью осознать.
бесполезное юзлесс говно, которое все равно в 90% случаев не покроет всех возможных вариантов при обработке ответов с сервера, выполнения кода, етс.
В дебагмоде же ты видишь все и сразу, без написания дополнительного кода и без лишних ожиданий по времени
Эту ситуацию также нельзя покрыть тестами.
Как и миллион других ситуаций. Юнит-тесты не гарантируют, что у тебя не будет багов или что ты покрыл все-все возможные случаи. Но они гарантируют, что юнит ведет себя в соответствии с теми спецификациями, которые ты сам для этого юнита написал.
Они покроют ровно столько, сколько ты позволишь им покрыть. В большинстве случаев тебе не нужно обрабатывать все-все ответы сервера, тебе не нужны все-все данные. Ты знаешь, какие тебе нужны изначально, и пишешь код под эти данные. Потом код расширяется, обрабатывает больше данных, больше случаев и т.д. Юнит-тесты помогают этому расширению, а так же изначальной верификации кода.
Я тебе скинул определение эксперимента, не маняврируй. Меняй слово "эсперимент" на "тест" или даже "юнит-тест" и говори, в чем видишь несоответствие.
>Но они гарантируют, что юнит ведет себя в соответствии с теми спецификациями, которые ты сам для этого юнита написал.
вообще у программиста, который уровнем чуть выше бегиннера код и так будет себя вести так, как ты его пишешь. Тесты, как и дебагмод, юзаются для выявления отсутствия проверок на нулл, где они нужны, либо же для обработки внештатных ситуаций (зашел в приложенько юез интернета, например).
>В большинстве случаев тебе не нужно обрабатывать все-все ответы сервера, тебе не нужны все-все данные.
э, че? Вообще код писался всегда с расчета на то, что всегда любой его участок может быть выполнен. И да, всегда и все ответы от сервера должны адекватно обрабатываться, а не так, что вот эти два отладил на ура, а все остальные похуй, как-нибудь будет.
так что:
>тебе не нужно обрабатывать все-все ответы сервера
в рамках одного приложения нужно
> тебе не нужны все-все данные
в рамках одного приложения нужно
>Потом код расширяется, обрабатывает больше данных, больше случаев и т.д.
И ты тратишь процентов 30 своего рабочего времени на нписание этих самых юниттестов, вместо того, чтоб писать рабочий код
>вообще у программиста, который уровнем чуть выше бегиннера код и так будет себя вести так, как ты его пишешь
На этом рассуждении можно закончить и послать тебя поработать над чем-то сложнее API прокладки в течение годика-двух. Нет проблемы написать (кое-как) рабочий код. Главные проблемы начинаются, когда тебе нужно этот код поддерживать и изменять.
>И ты тратишь процентов 30 своего рабочего времени на нписание этих самых юниттестов, вместо того, чтоб писать рабочий код
Откуда ты знаешь, что пишешь рабочий код, если ты его не протестировал? Он магически работает или ты примерно почувствовал? Если ты "тестируешь" в консоли, то почему в консоли, а не автоматическим тестом, который можно повторить в любой момент в любой ситуации и в котором кода не сильно больше?
Просто ты говнокодер, который не умеет писать качественный самоподдерживающийся самодокументированный самотестируемый код. А еще ты омежка и не уверен в себе.
>На этом рассуждении можно закончить и послать тебя
главное держи нас в курсе
>чем-то сложнее API прокладки в течение годика-двух
та вот года 4 уже пишу что-то посложнее и представляешь, обходился все время без юнит тестов, когда же попробовал их юзать, то понял, какая это бесполезная потеря времени.
>Главные проблемы начинаются, когда тебе нужно этот код поддерживать и изменять.
ебать, и как тебе, сильно помогают тесты при добавлении и расширении функционала?
>Откуда ты знаешь, что пишешь рабочий код, если ты его не протестировал?
дебаг мод + прямые руки + минимальное тестирование в духе: написал функционал, запустил, посмотрел что все ок, с остальным работает
>а не автоматическим тестом, который можно повторить в любой момент в любой ситуации и в котором кода не сильно больше?
я об этом уже написал двумя постави выше
>та вот года 4 уже пишу что-то посложнее и представляешь, обходился все время без юнит тестов
Ты не одинок, миллионы разработчиков пишут без юнит-тестов и миллионы разработчиков сталкиваются с одинаковыми проблемами гниющего кода и кода, который со временем нельзя поддерживать от слова вообще, если не проводить полный рефакторинг. TDD ставит целью решить хотя бы часть этих проблем, и насколько я могу судить, очень хорошо справляется.
>ебать, и как тебе, сильно помогают тесты при добавлении и расширении функционала?
Напрямую? Я знаю, что мой протестированный юнит выполняет все требования, которые я на него возложил год назад, потому что все тесты проходят. Даже если я что-то добавил или зарефакторил. Откуда ты знаешь, что твой юнит годовой давности до сих пор работает, когда ты решишь его зарефакторить без тестов?
>дебаг мод + прямые руки + минимальное тестирование в духе
Ну то есть ты пробуешь свой код в дебаг моде, примерно чувствуешь его работоспособность "прямыми руками", и "тестируешь" в консоли? Сколько времени ты тратишь на дебаг и на свое консольное тестирование даже при изначальном написании, не говоря уже о расширении кода, когда тебе приходится заново все запускать и смотреть? Сколько функционала ты пропускаешь или забываешь? Ты уверен, что это дает тебе выигрыш во времени по сравнению с "написал тест-написал код-написал тест-написал код"? Я вот почти наверняка могу тебе сказать, что выигрыша во времени твой подход не дает вообще никакого, даже в short-term ситуации, не говоря про long-term. Потому что пробовал и то, и то.
Что и требовалось доказать.
Потому что тесты пишут все разработчики без исключения (ну, быть может за исключением каких-нибудь дедов в НИИ). Сама формулировка вопроса как бы намекает, что вопрошающий - школьник или студент, а потому все равно не поймет ответ в виду отсутствия опыта.
Но если так хочется, очевидный пример - часто ловлю неучтенные констрейнты в данных через тесты. Тут забыл длину строки проверить в модели, там забыл корректную ошибку вернуть, и так далее.
Вроде упоминали же. Ну вот я выше как раз о нем и говорил, лол.
>Тут забыл длину строки проверить в модели, там забыл корректную ошибку вернуть, и так далее.
Лолшто блядь? Ты забыл написать проверку в функции, но не забыл написать под нее тест. Как это? Я собственно и спрашиваю конкретных примеров, потому что на них очевидно какую чушь несут TDD-чушки. Наверное я и правда тупой школоло и это выше моего понимания.
>из-за какого-то хитрого сочетания состояния и входных данных
См. предыдущие два поста, тесты ровно для отлова этого и нужны.
Те, кто в танке, могут посмотреть презенташки:
https://www.youtube.com/watch?v=zi0rHwfiX1Q
https://www.youtube.com/watch?v=iW2J7Of8jsE
https://www.youtube.com/watch?v=H18vxq-VsCk
Алсо, я забыл, как называется классический ток (вроде тот же Hughes его давал), где на пальцах объясняется, как это работает на примере тестирования сишной имплементации списка. Кто помнит - доставьте, молю.
>Наверное я и правда тупой школоло и это выше моего понимания.
Ты начал прозревать, анон.
Смотри, ты описываешь воркфлоу своего сервиса в виде графа. Потом задаешь грубые ограничения на данные, которые этот сервис ожидает. Ну например id должен быть интом, а name - строкой. Потом запускаешь эту фигню, и она лазит туда-сюда по твоему сервису, дергает апи и проверяет, все ли работает как ожидается, а ты идешь пилить следующую фичу. Потом минут через 10 она падает с эксепшном, ты осознаешь, что забыл сделать проверку на какую-ту хуйню. Добавляешь зафейленный вызов в качестве тест-кейса в юнит-тесты, ред-фикс-грин. Итерируешься дальше.
Но вообще, нет смысла тебе это описывать, если ты не в теме - все равно для тебя это будут какие-то общие слова. Лучше книжки читай, серьезно.
>ты осознаешь, что забыл сделать проверку на какую-ту хуйню.
>Добавляешь зафейленный вызов в качестве тест-кейса в юнит-тесты, ред-фикс-грин.
> Итерируешься дальше.
>Лучше книжки читай, серьезно.
Нет уж спасибо, мне карго-культная ссанина от дядюшки Боба и компании совершенно не интересна.
>Потом запускаешь эту фигню, и она лазит туда-сюда по твоему сервису, дергает апи и проверяет, все ли работает как ожидается, а ты идешь пилить следующую фичу. Потом минут через 10 она падает с эксепшном
Кто блядь куда лазает, быдлойд блядь научись нормально уже изъяснятся, еще блядь умным дядей прикидывается.
>Откуда ты знаешь, что пишешь рабочий код, если ты его не протестировал?
У него gut feeling, лол. У меня вообще стойкое чувство, что тобой тут одни лабоделы спорят.
>минимальное тестирование в духе: написал функционал, запустил, посмотрел что все ок
Я В КАЖДОЙ ВТОРОЙ СТРОКЕ НАПИШУ ASSERT 1+1==2
У МЕНЯ 100% ПОКРЫТИЕ
МОЙ КОД НЕ МОЖЕТ НЕ РАБОТАТЬ!!!1111!!!!
какие же верунчики жалкие
Ты не знаешь, что такое регресионное тестирование? Сочувствую.
Я имел в виду книжки по основам программирования и разработки ПО. Дядю Боба тебе пока рано читать, ничего полезного не почерпнешь.
Анон, я не виноват, что ты тупенький. Ключевые слова для гугла еще полтреда назад озвучили, я даже на презенташки ссылки дал. Если ты неспособен самостоятельно искать и разбираться в новой информации, то тебе не место в этом разделе энивей. Лол, just kidding, в /зк чувствуй себя как дома.
>Я В КАЖДОЙ ВТОРОЙ СТРОКЕ НАПИШУ ASSERT 1+1==2
Ну земля тебе пухом, чо.
>Ключевые слова для гугла еще полтреда назад озвучили, я даже на презенташки ссылки дал
Дебик перечитай что ты написал там же хуйня бессвязная. Лучше своей мамке сочувствуй.
охуеть, ну пиши по 100 юниттестов для каждого метода и главное пикрилы смешные находи, чтобы "тралеть дурачкоф, каторые не панимают, что юниттистиравание прикольна )))0))))) ну мааам, ну прикольна жи!!!1"
а по делу - и по времени и по написанию дополнительного кода оптимальнее и быстрее вариант с "написал код - прогнал через дебаггер - прогнал чеерз ручной личный тест вместе с текущим классом по ситуации", чем "написал метод в 30 строк за 10 минут, а потом пишу 2 часа 10 тестов, чтоб все точно работало и если что показало мне отсутствие проверки на нулл, которая и так очевидна должна быть"
Ты тупой?
Держи: ,,,,
>пиши по 100 юниттестов для каждого метода
Зачем?
>а потом пишу 2 часа 10 тестов
Зачем? Если у тебя нет органических поверждений мозга, то ты не будешь писать 10 тестов 2 часа.
Если же речь идет о ТДД, то там на написание тестов как таковое время вообще практически не тратится, так как разработка ведется через тестирование - то есть ты дизайнишь свои системы и алгоритмы с помощью тестов. Если в твоем коде нет никаких алгоритмов и тебе не нужно думать, перед тем как написать код, - тогда да, ТДД тебе не поможет, но среди разработчиков в целом ты в меньшинстве.
Наконец, всерьез утверждать, что руками проверять быстрее, чем автоматизировать тестирование - ну это просто смешно, анон. Ты там сайтики на пхп клепаешь, или что?
Анон, ну со стороны же видно, что в вашей дискуссии с тем аноном ты слился, - не усугубляй. Твой троллинг))0) тупостью из вас двоих выставляет дурачком именно тебя.
Пруфов утверждения, что твоя мать - спидозная шлюха ты, я так понимаю, требовать не станешь? Со стороны очень видно, что шлюха.
Почему столько дегенератов в зк, чего вам в бэ не сидится?
Твои охуительные истории уже просто доебали. То ты у нас квикчекер описывающий свойства. То ты фаззишь свою систему на прочность, квикчеком лол, если я верно распарсил твой сблев. То ты у мамки ТДД. Готов поставить яйца что ты маня-фантазер и сам не далеко ушел от laba1, laba2, laba3 ...
>Почему столько дегенератов в зк, чего вам в бэ не сидится?
Хороший вопрос, анон. Так почему? Сидели бы в б и там обсуждали своих мамок.
По теме есть чо? Яйца мне бандеролью пришлешь.
>По теме есть чо?
Дебик не пизди
Только Ситхи возводят всё в абсолют.
>Что и требовалось доказать.
Успокойся, доказыватель. Если тут что и доказано, то лишь то, что мне на тебя посрать.
>Дебик
А я Леша. Так по теме есть чо?
Было бы посрать - не ответил бы. Не обижайся так.
>А я Леша
Леша - ты дебик.
>Ну то есть ты пробуешь свой код в дебаг моде, примерно чувствуешь его работоспособность "прямыми руками", и "тестируешь" в консоли? Сколько времени ты тратишь на дебаг и на свое консольное тестирование даже при изначальном написании, не говоря уже о расширении кода, когда тебе приходится заново все запускать и смотреть? Сколько функционала ты пропускаешь или забываешь?
Мой код разбит на очень малые кусочки, которые легко понять и модифицировать, их достаточно пару раз ручками протестить - во время написания и после рефакторинга. А с этими вашими тестами TDD я буду долго разбираться, это они не работают после рефакторинга, или код, лол. Для всего остального есть функциональные тесты.
Дядяебство оказывается еще хуже, чем я думал:
https://www.hillelwayne.com/post/uncle-bob/
гоните_насмехайтесь.тхт
https://www.hillelwayne.com/post/uncle-bob/
гоните_насмехайтесь.тхт
Еще забыл сказать, что всегда выстраиваешь идеальную архитектуру из своих кусочков, что наперед пишешь их выполняющими все будущие требования и что с легкостью ориентируешься в море из 10000 файлов на 5 строк, потому что если твой компонент содержит больше строк кода, то он уже не маленький и содержит достаточно логики, чтобы был смысл ее тестировать. И вообще ты сверчеловек, не допускающий ошибок.
>А с этими вашими тестами TDD я буду долго разбираться, это они не работают после рефакторинга, или код
Тебе нужно поучиться пару месяцев писать такие тесты, которые не ломаются от изменений внутренней структуры кода и ты всегда знаешь, что если тест не работает, то и код не выполняет нужных требований. Это не так просто, как кажется, написанию хороших юнит-тестов и тестов в целом нужно учиться точно так же, как и написанию хорошего кода. То же самое касается их архитектуры.
Автор поста почему-то считает, что дядя боб ратует за "выкините все, оставьте юнит-тесты, вам больше ничего и не надо". Но это очевидно пиздеж, его позицию скорее можно описать как "90% самых распространненых проблем, перед которыми сталкиваются программисты сейчас, можно решить через введение дисциплины тестирования". Нельзя протестировать всю систему юнит-тестами, но они должны составлять основу тестового покрытия этой системы. И разумеется сверху у тебя будут интеграционные, системные и прочие тесты, о нужности которых спорить будет разве что совсем зеленый студент. Говорить, что юнит-тесты можно заменить property-based тестами - это как говорить, что юнит-тесты можно заменить интеграционными. Это очевидно бред, у них разные задачи.
>тесты, которые не ломаются от изменений внутренней структуры кода
Ты про акцептанс тесты что-ли?
>Автор поста почему-то считает, что дядя боб ратует за "выкините все, оставьте юнит-тесты, вам больше ничего и не надо".
Автор вообще-то приводит ссылки на "эта все нинужна"-посты твоего фюрерка.
Чет люто проиграл с треда. Подахуел с того, какой процент дурачков топит за юниттесты. Перепробовал 7 контор (включая в ес), нигде толком их не признают и не юзают, только в снг находятся дрочеры, по непонятным причинам готовые тратить на это время. А самое смешное - это то, что аргумент топильщиков за юнит тесты откровенно детские, либо "ну ничего не разрушится после расширения функционала" либо "быстро найдутся дыры в логике в коде". В первом случае этот факт должен как бы разуметься сам собой, в противном случае если вы не в состоянии нормально добавлять функционал в существующий код, то вы даже не программист толком. Во втором они просто не понимают, что время на написание тестов (которые к тому же реально проверяются очевидные моменты, которые почти всегда мало мальски адекватным программером учитываются сразу) затрачивается больше, чем на дебагер и прогонку после компиляции.
Которые ты(и возможно даже он) не читал. Особенно я подохуел с того, что он взял пост с идеей "БД - это просто деталь, не нужно строить свое приложение вокруг БД" и подписал его как "ВОТ ТУТ ДЯДЯ БОБ ГОВОРИТ ЧТО DATA INTEGRITY ЭТО ПЛОХА И НИНУЖНА!!!". Самая настоящая демагогия.
Сразу видно, что о TDD слышал краем уха от хуй знает кого и хуй знает где, при этом сам либо не пробовал, либо не смог подойти с непредвзятой стороны и поучиться процессу хотя бы месяц в свободное от работы время.
>время на написание тестов затрачивается больше, чем на дебагер и прогонку после компиляции.
Разве что в хэллоу-ворде. Как только у тебя на руках оказывается приложение с хоть чуть-чуть вменяемой по размеру кодовой базой, то прогонять ВСЕ вручную становится нереально. А если ты не прогнал все, то откуда ты знаешь, что ВСЕ работает?
Никто не говорит, что без TDD писать нереально, но факт в том, что TDD помогает тебе писать лучший код и помогает не замедляться со временем, когда у тебя на руках оказывается целая куча легаси-лапши, продираться через которую проблемнее и проблемнее с каждым годом, если ты не можешь ее эффективно зарефакторить(а без тестов ты этого сделать не можешь вообще никак). Вообще по этому поводу дохуя мнений, но я, как и многие TDD-шники считаю, что написание юнит-тестов меня не замедляет даже в short-term ситуации, по сравнению со старым стилем разработки. Потому что 90% времени я не делаю вообще ничего, кроме как пишу код. Написал тест - тест красный - написал код - тест зеленый. Мне не нужно проверять отдельные моменты руками, мне не нужно открывать дебагер. Достаточно написать юнит-тест, который по сути состоит из двух строчек - вызов функции с параметром, проверка результата. В long-term же TDD выигрывает просто по определению.
>потому что если твой компонент содержит больше строк кода
Я говорю о внутренней логике компонента, а не его апи. У меня обычно логика разбита на 100500 маленьких функций, при взгляде на которые прозрачно и понятно что они делают и для чего нужны. Редко, когда есть длинные простыни. Для каждой такой функции писать юнит-тесты очень затратно, так как при рефакторинге они могут сильно изменяться, вплоть до удаления/создания новых. Дешевле тестить их ручками. Но само API компонента покрыто именно функциональными тестами.
>не допускающий ошибок.
Допускаю, но они ловятся не юнит тестами, а упомянутыми функциональными тестами.
Ты пытаешься тестировать внутреннюю логику компонента, а нужно тестировать только API. Нет разницы, на сколько функций он разбит или как эти функции названы, или даже в каких файлах они находятся, если они всего лишь помогают реализовать логику одного компонента. Ты воспринимаешь юнит-тесты как "если у меня есть функция, то к ней обязательно нужен юнит-тест", а нужно их воспринимать как потребителя твоего API, только и всего. Тогда не будет никаких проблем с ломающимися от рефакторинга тестами и ты точно будешь знать, что если юнит-тест не проходит, то в приложении что-то сломалось, так как юнит перестал работать в соответствии с ожидаемой от него спецификацией.
>Ты воспринимаешь юнит-тесты как "если у меня есть функция, то к ней обязательно нужен юнит-тест"
Тогда это ломает тезис ОПа и дебаггер, в этом случае нужен: компонент не работает, но не понятно, что у него сломалось при рефакторинге/разработке. Для того, чтобы убрать дебаггер, надо всю внутреннюю логику тестами покрыть, тогда точно баг тестами найдется.
>вы не правильно читаете Святого Отца!!1111
ясн
Зачем тебе дебагер для этого? У тебя есть изолированный компонент, ты его постепенно рефакторишь, выносишь функции и сабкомпоненты и каждый раз прогоняешь тесты, чтобы убедиться, что он до сих пор выполняет все спецификации. Если что-то ломается, то тебе почти сразу видно, почему оно сломалось и где.
Бывает всякая хуйня со стейтом, взаимодействием с миром и тд, что без дебаггера хуй поймешь.
Юнит-тест не взаимодействует с миром, иначе это не юнит-тест.
>их достаточно пару раз ручками протестить
Зачем делать что-то руками, если это может сделать за тебя компьютер?
Property-based тесты могут быть как юнит-тестами, так и неюнит-тестами. "Property-based" ничего не говорит о гранулярности тестирования - это ортогональные вещи.
>что время на написание тестов ... затрачивается больше, чем на дебагер и прогонку после компиляции.
Это, конечно, неправда. Я сравнивал. И не только я, кек. Тдд действительно в итоге выходит быстрее. Вот только лично у меня не хватает мозгов дисциплины, чтобы строго ему следовать на практике.
>Дешевле тестить их ручками.
Не, ну вы просто капец, серьезно. Ты же в курсе, что написание одного кейса юнит-теста занимает ровно столько же времени, сколько проверка этого же кейса "ручками"? Единственное отличие - в будущем этот кейс будет автоматически проверяться снова при каждом изменении кода. О чем вы вообще говорите?
Расскажи мне, как ты проверяешь "ручками" и как ты пишешь кейсы в тестах, что у тебя второе стабильно занимает больше времени, чем первое. Не подъебки ради, мне действительно интересно.
>Юнит-тест не взаимодействует с миром, иначе это не юнит-тест.
https://en.wikipedia.org/wiki/No_true_Scotsman
Охуенно жить в мире где
Бесконечная память.
В компиляторах/интерпретаторах нет ошибок
В ОС нет ошибок
В стандартной библиотете нет ошибок
В libc нет ошибок
Data race гарантированно воспроизводятся и ловятся тестами
* Продакшен и девелопмент окружения идентичны до атома
Короче, охуенно кататься на сферическом коне по просторам вакуума.
И это вообще не трогая языки с undefined behavior которые могут пройти 300% тестов и сдохнуть как сучка в продакшене.
Пример из жизни (упрощенный) на С.
#include <assert.h>
int return_one()
{
int a = 1;
return a;
}
int return_two()
{
int a; // туннелинг переменной в функцию
return a+1;
}
int main()
{
assert(return_one() == 1);
assert(return_two() == 2);
return 0;
}
Запускай хоть 40 раз все работает
>>gcc main.c && ./a.out && echo $?
>>0
>https://en.wikipedia.org/wiki/No_true_Scotsman
Но ведь он буквально процитировал определение юнит-теста. Зачем ты передергиваешь?
>Бесконечная память.
>В компиляторах/интерпретаторах нет ошибок
>В ОС нет ошибок
Сейчас бы в юнит-тестах беспокоится об ошибках в ОС и компиляторе, лол. Анон, ну не выставляй себя клоуном, нормально же сидели.
>И это вообще не трогая языки с undefined behavior
Так это не "языки с undefined behavior", это код на языках с undefined behavior. Угумс?
Если не умеешь писать на си - не берись. Ошибки из твоего поста даже средненький второкурсник не допустит, если что.Про линтеры, валгринды и варнинги компилятора я и вовсе молчу.
>Но ведь он буквально процитировал определение юнит-теста
Мне несколько насрать на формальное определение юнит теста.
Меня, как практического программиста ,интересует объективная реальность.
Работадателя интересует объективная реальность.
И объективные тесты на реальном железе.
И работоспособность программного продукта.
Не зависящая от фаз луны.
Чего юнит-тесты дать не могут сами по себе.
Если мы говорим о всей пирамиде тестов, см картинку
то еще куда не шло. Но бегать с голым задом и кричать, что "ЮНИТ ТЕСТОВ ХВАТИТ ВСЕМ!!!" как оп
на мой взгляд глупо.
>Сейчас бы в юнит-тестах беспокоится об ошибках в ОС и компиляторе
Не надо?
О каком уровне программирования мы говорим? Лабораторные работы? Домашнее задание?
>Если не умеешь писать на си - не берись. Ошибки из твоего поста даже средненький второкурсник не допустит, если что
Начали с юнит тестов, закончили "ПРОСТО НЕ ДОПУСКАЙТЕ ОШИБКИ".
Зачем юнит тесты, когда можно по вашей логике, просто не допускать ошибки?
Вы CVE читали когда нибудь? Вы знаете какие ошибки допускают разработчики?
>Мне несколько насрать на формальное определение
Ясно. Дальше не читал, там примерно то же самое.
ОП треда съебался сразу после создания, мы тут без него сидим. И никто нигде ни разу не упомянул, что если ты пишешь юнит-тесты, то можешь не писать никакие другие. Разумеется ты должен писать и другие типы тестов, и разумеется они ловят те ошибки, которые юнит-тест не может поймать никак, просто потому что это не его задача.
Тот, кто сказал это, тоже ситх, выходит.
Я 2 поста написал и забыл про тред.
Пришел теперь и охуеваю это все читать.
Орнул с юнит тестов, которые взаимодействуют с окружающим миром.
ОП
А КАК ЖИ БАГИ В КАМПЕЛЯТОРЕ!?! Я ТЕСТИРУЮ ЮНИТТЕСТАМИ БАГИ В КАМПЕЛЯТОРЕ, А ВЫ И ДАЛЬШЕ СИДИТЕ И ПИШИТЕ СВАИ ЛАБЫ!!! И ВООБЩЕ МНЕ ПОХУЙ НА ОПРЕДИЛЕНИЕ ЮНИТТЕСТА!!
Ну на сумасшедших я внимание не обращаю.
Еще "порадовало" идея о том, что тестирование означает создание теста на каждую отдельную функцию. По такой логике, использование лямбда-функций уже невозможно в ТДД, а ЗНАЧИТ ТДД-ПИТОХИ САСИРУЮТ АЗАЗА
Запомните дети, даже 100% покрытие означает не создание теста на каждую функцию, а то, что при тестах каждый кусок кода был запущен, каждый иф, каждая загогулина.
А применение ТДД не означает даже 100% покрытие и не отменяет разумной идеи "максимальный результат за минимальную работу". Можно начать с тестирования ключевых методов класса типа конструктора, а продолжить покрытием нескольких основных методов, которые сами вызывают другие методы,
А вот факт того, что рука тянется к дебагу обозначает, что пришло время углубиться во фрактал ТДД и повысить покрытие.
ЕСЛИ У ТЕБЯ ЕСТЬ ВРЕМЯ НА РАССТОНОВКУ КРАСНЫХ КРУЖОЧКОВ, ТО ПОТРАТЬ ЕГО НА НАПИСАНИЕ ТЕСТА
Введение в генеративные тесты для нубов:
https://dev.to/jdsteinhauser/intro-to-property-based-testing-2cj8
https://dev.to/jdsteinhauser/intro-to-property-based-testing-2cj8
Такое-то сектанство
>нахуя учиться на врача 15 лет? такое-то сектанство
>нахуя надевать каску при работе на стройке? такое-то сектанство
>нахуя double-entry bookkeeping? такое-то сектанство
>нахуя пристегиваться в машине? такое-то сектанство
>нахуя тестировать весь код? такое-то сектанство
Фактически, есть только 2 сценария использования дебага:
1) Вы фиксите чье-то легаси.
2) Вы игнорируете юнит-тесты и ваши юниты слишком большие чтобы вы могли их полностью осознать.