Соер! Очень прошу не упрощай ролики из-за недовольных. Ты единственный в ютубе кто делает грамотные материалы. Остальные просто документацию пересказывают. Я тоже не все с первого раза понимал, но со временем понял гораздо больше чем от всех других блогеров. Те кто хочет разобраться готовы потратить время на твои видео, зато разобраться как надо!
ну я говорил не об упрощении, а подаче информации... Схематически нарисовать, выделить самое важное, шрифт в редакторе более привычный большинству и т.д. Этотвсе мелочи и придырки, но это в итоге больше аудитория... Но, как потом и написал, недовольным в первую очередь был потому что уже засыпал, когда включил видео. А на свежую голову все получше...
00:00 Start 08:27 Initialisation of the project, TypeScript, and Jest in the project 10:00 Stub, Fake, Dummy, Mock 14:40 BDD - TDD 16:03 - example of a test - describe, it, expect, set, and reset methods 39:18 Summary
Я имея огромный опыт тестирования пришел к выводу, что лучший способ тестирования - это перебор множества комбинаций входных данных. Комбинации генерируются автоматически, и их может быть десятки тысяч. И если уж совсем сложный модуль, то написать под него нагрузочный тест со случайными комбинациями входных данных. Эти два метода могут выполняться от пары минут до пары часов, но зато выявляют даже очень редкие ошибки. Имея очень хорошо протестированные модули, дальше будет проще строить из них что-то более сложное. Покрытие кода имеет мало значения, т.к. если программа выполнилась в определенном месте, то это совершенно не значит что это место в программе написано корректно. Имеет значение покрытие различных видов комбинаций входных данных и условий выполнения программы.
Про mock тестирование интересно. Если можно, поделитесь знаниями. И прошу, не нужно упрощений в повествовании, лучше комментарии сложных разделов в повествовании. Спасибо вам!
Полностью согласен, один из немногих авторов, который имеет достаточный багаж знаний, чтобы говорить сложно о сложно. Просто о сложном в интернете и так навалом)
Здравствуйте. Сейчас я следую (в том числе) методологии TDD и так выходит, что объём кода тестов у меня превышает объём тестируемого кода. Вопрос: стоит ли сокращать код тестов, или это нормально? Может, стоит уделить время рефакторингу кода тестов, чтобы его стало меньше?
Каеф) В языках вроде C++ выгодно использовать интерфейсы компонентов (DIP) из-за возможности легко заMock'ать эти компоненты, передаваемые по интерфейсу
Наследование по сути в памяти выглядит очень подобно обёртке над классом, да с VFT и некоторыми усложнениями А js без этих ухищерений и мок не скрываясь работает как обёртка над классом, точнее его прототипом
Является ли возникшая по ходу дела история с високосными годами примером собственно успешного тестирования, выявившего баг в тестируемом коде; вынудившего менять тестируемый код?
У меня с тестированием такая же проблема как с ООП была. Вроде все понятно, но как это использовать в реальной работе? Обычно поведение у обьектов болеее сложное, и что именно тестировать в каких случаях. Пазл никак не складывается. С ооп в итоге сложилось все, когда попалась задача которая иначе не решалась.
@@datorikai9911надо было обьединить информацию из двух xml файлов. Таким образом чтобы она не дублировалась. Пришлось распарсить эксмл в обьекты, и потом собрать обратно. Каждый обьект получал на вход ряд строчек, сам находил в них ключевые значения, и потом уже эти обьекты сравнивались и рендерились в новую хмлку
@@mikhailkh8560 огромное спасибо, учу учителей, которые умные стараются понять, остальным трудно перейти со структурированного и они только php и никакого руthon
@@mikhailkh8560 не верю что остались языки, в которых такая задача делается не в пару строк кода за пару минут, да ещё ООП городить, что за язык такой, делфи?
@@KonstantinPrydnikov1 я в эксмл не эксперт, может и можно. Я правда сначала пару дней потратил на то чтобы узнать как это сделать, но так и не нашел. Как свои обьекты описать и сохранить в эксмл нашел, и это не три строчки. Как свои обьекты из эксмл загрузить и превратить в обьекты тоже нашел. А как хер пойми чью схему сразу превратить в обьекты бизнес логики - такого не находил :D на шарпах я это делал.
спасибо за видео хотел дополнить про избыточность, попытаюсь пояснить на данном примере - не всегда избыточность - это плохо. Предположим мы убрали условно "избыточные" тесты и видим упавший тест "should convert full years to string" - сможем ли мы однозначно сказать, что упал именно тестируемый функционал, или, например, упала инициализация класса, а этот тест упал как следствие или что-то? В более сложных случаях (или когда мы видим только названия тестов, например, в пайплайне) хотелось бы однозначнее и быстрее определять проблему без дополнительного просмотра логов или дебага.
Думаю Соеру надо поучиться у Ильи Климова рассказывать простым языком о сложном) А то получилось сложно о простом и в итоге непонятно для какой аудитории) Это же урок... Соер просто уже не помнит, что такое быть новичком)) Кто хочет понять, что такое тестирование, то есть хорошее видео у Тимура (Ulbi tv)
У Соера академический подход, у Ulbi развлекательный. Соер всегда рассказывает теорию и принципы, которые помогают принимать решение. У Ulbi вообще ничего полезного в видосе не нашел, он просто пересказал документацию. Я лучше чем у Соера нигде не находил объяснений.
@@РоманВойтук Ulbi пересказад документацию?) Он только показал, как пользоваться документацией, а кроме этого привел примеры всех возможных случаев, начиная с простых и заканчивая асинхронными. А потом еще и показал, как это делается с фреймворком. Да, у Соера академический подход. Поэтому половину видео (где теория) он "академической терминологией" рассказывает то, что в итоге в памяти практически ни у кого не останется при такой подаче, имхо. Там где примеры, то уже полезнее
Хотя, если честно, то вчера видео смотрел уже лежа в кровати и засыпая... И показалось слишком сухой и сложной теория. А сегодня уже смотрю днем и все кажется понятным) но все равно, например, даже рассказ о границах можно было бы схематически нарисовать - так было бы понятнее тем, кто не поймет о чем речь...
Слишком много фанатства, чтобы начать работать с технологией нужно смотреть Ulbi и не тратить время ни на что другое. Чтобы попробовать чуть подробнее разобраться в теме - Соера, тут каждый выбирает для себя
Soer, огонь видео для меня, как новичка в этом деле. Всё понятно и интересно было. Благодарю! и не понимаю, куда ещё упрощать... Для, так сказать, обратной связи у меня опыт программирования 2 года на пхп, тесты никогда не делал, только слышал о них. Есть что-то такое, что можно порекомендовать какую-то полезную/хорошую литературу или ресурсы/каналы по этому тестированию в целом, помимо документации к фреймворкам?
Зачем же так сложно все объяснять? Такое впечатление, что видео направлено исключительно на других миддл и синьор разработчиков... Проще надо быть... Новичкам это лучше не смотреть. Я бы рекомендовал писать код построчно, объясняя что именно вы пишите и зачем - так было бы гораздо яснее, а не по написанному сразу что-то сверху наваливать :) Мой мозг взорван, и вы очень умный))
@@Mike-hp3fh console.log() - наше всё! Ловить баги - этж круче чем рыбалка и охота в одном флаконе! =) А сколько всего нового узнаёшь о своём коде и ЯП в процессе! Мммм! Каеф! =)))
Соер! Очень прошу не упрощай ролики из-за недовольных. Ты единственный в ютубе кто делает грамотные материалы. Остальные просто документацию пересказывают. Я тоже не все с первого раза понимал, но со временем понял гораздо больше чем от всех других блогеров. Те кто хочет разобраться готовы потратить время на твои видео, зато разобраться как надо!
ну я говорил не об упрощении, а подаче информации... Схематически нарисовать, выделить самое важное, шрифт в редакторе более привычный большинству и т.д. Этотвсе мелочи и придырки, но это в итоге больше аудитория... Но, как потом и написал, недовольным в первую очередь был потому что уже засыпал, когда включил видео. А на свежую голову все получше...
00:00 Start
08:27 Initialisation of the project, TypeScript, and Jest in the project
10:00 Stub, Fake, Dummy, Mock
14:40 BDD - TDD
16:03 - example of a test - describe, it, expect, set, and reset methods
39:18 Summary
большое спасибо за информацию. Как раз интересуюсь тестированием именно на TS.
Огромное спасибо. Так коротко и при этом ёмко м понятно . Лучшее объяснение, которое я слышал.
Хорошее информативный ролик) Хотя и местами действительно не самый простой для восприятия и нужно поразбираться)
Плюсую за видео про тестирование с mock'ами. И еще про тесты асинхронного кода было бы полезно.
Я имея огромный опыт тестирования пришел к выводу, что лучший способ тестирования - это перебор множества комбинаций входных данных. Комбинации генерируются автоматически, и их может быть десятки тысяч.
И если уж совсем сложный модуль, то написать под него нагрузочный тест со случайными комбинациями входных данных. Эти два метода могут выполняться от пары минут до пары часов, но зато выявляют даже очень редкие ошибки.
Имея очень хорошо протестированные модули, дальше будет проще строить из них что-то более сложное.
Покрытие кода имеет мало значения, т.к. если программа выполнилась в определенном месте, то это совершенно не значит что это место в программе написано корректно. Имеет значение покрытие различных видов комбинаций входных данных и условий выполнения программы.
Спасибо за содержательное видео!
Спасибо за качественные материалы, творческих успехов вам;)
Комментарий для продвижения видео алгоритмами ютуба.
Про mock тестирование интересно. Если можно, поделитесь знаниями. И прошу, не нужно упрощений в повествовании, лучше комментарии сложных разделов в повествовании. Спасибо вам!
Полностью согласен, один из немногих авторов, который имеет достаточный багаж знаний, чтобы говорить сложно о сложно.
Просто о сложном в интернете и так навалом)
полностью согласен с автором, очень хорошее видео
Шикарный видос.
Прочитал: "Тесть - что нужно" :)
Здравствуйте. Сейчас я следую (в том числе) методологии TDD и так выходит, что объём кода тестов у меня превышает объём тестируемого кода. Вопрос: стоит ли сокращать код тестов, или это нормально? Может, стоит уделить время рефакторингу кода тестов, чтобы его стало меньше?
Это нормально.
Нормальное соотношение 1 к 5)
Посмотрите курс unit тестов от Ильи Климова
Хорошее видео!
Соер, где продолжение разработки программы!? 🤔 ждём ждём , а его все нет и нет...
Спасибо за контент.
А можно такое же видео об автоматизации UI части на jest ?
Каеф)
В языках вроде C++ выгодно использовать интерфейсы компонентов (DIP) из-за возможности легко заMock'ать эти компоненты, передаваемые по интерфейсу
Наследование по сути в памяти выглядит очень подобно обёртке над классом, да с VFT и некоторыми усложнениями
А js без этих ухищерений и мок не скрываясь работает как обёртка над классом, точнее его прототипом
Является ли возникшая по ходу дела история с високосными годами примером собственно успешного тестирования, выявившего баг в тестируемом коде; вынудившего менять тестируемый код?
У меня с тестированием такая же проблема как с ООП была. Вроде все понятно, но как это использовать в реальной работе?
Обычно поведение у обьектов болеее сложное, и что именно тестировать в каких случаях. Пазл никак не складывается.
С ооп в итоге сложилось все, когда попалась задача которая иначе не решалась.
Можно эту задачу?
@@datorikai9911надо было обьединить информацию из двух xml файлов. Таким образом чтобы она не дублировалась.
Пришлось распарсить эксмл в обьекты, и потом собрать обратно. Каждый обьект получал на вход ряд строчек, сам находил в них ключевые значения, и потом уже эти обьекты сравнивались и рендерились в новую хмлку
@@mikhailkh8560 огромное спасибо, учу учителей, которые умные стараются понять, остальным трудно перейти со структурированного и они только php и никакого руthon
@@mikhailkh8560 не верю что остались языки, в которых такая задача делается не в пару строк кода за пару минут, да ещё ООП городить, что за язык такой, делфи?
@@KonstantinPrydnikov1 я в эксмл не эксперт, может и можно. Я правда сначала пару дней потратил на то чтобы узнать как это сделать, но так и не нашел. Как свои обьекты описать и сохранить в эксмл нашел, и это не три строчки. Как свои обьекты из эксмл загрузить и превратить в обьекты тоже нашел. А как хер пойми чью схему сразу превратить в обьекты бизнес логики - такого не находил :D на шарпах я это делал.
спасибо за видео
хотел дополнить про избыточность, попытаюсь пояснить на данном примере - не всегда избыточность - это плохо. Предположим мы убрали условно "избыточные" тесты и видим упавший тест "should convert full years to string" - сможем ли мы однозначно сказать, что упал именно тестируемый функционал, или, например, упала инициализация класса, а этот тест упал как следствие или что-то?
В более сложных случаях (или когда мы видим только названия тестов, например, в пайплайне) хотелось бы однозначнее и быстрее определять проблему без дополнительного просмотра логов или дебага.
Стоит ли проверять Age на Truthy, если и так используется typescript?
65535 - это что граница integer?)
Думаю Соеру надо поучиться у Ильи Климова рассказывать простым языком о сложном) А то получилось сложно о простом и в итоге непонятно для какой аудитории) Это же урок...
Соер просто уже не помнит, что такое быть новичком))
Кто хочет понять, что такое тестирование, то есть хорошее видео у Тимура (Ulbi tv)
У Соера академический подход, у Ulbi развлекательный. Соер всегда рассказывает теорию и принципы, которые помогают принимать решение. У Ulbi вообще ничего полезного в видосе не нашел, он просто пересказал документацию. Я лучше чем у Соера нигде не находил объяснений.
@@РоманВойтук Ulbi пересказад документацию?) Он только показал, как пользоваться документацией, а кроме этого привел примеры всех возможных случаев, начиная с простых и заканчивая асинхронными. А потом еще и показал, как это делается с фреймворком.
Да, у Соера академический подход. Поэтому половину видео (где теория) он "академической терминологией" рассказывает то, что в итоге в памяти практически ни у кого не останется при такой подаче, имхо. Там где примеры, то уже полезнее
Хотя, если честно, то вчера видео смотрел уже лежа в кровати и засыпая... И показалось слишком сухой и сложной теория. А сегодня уже смотрю днем и все кажется понятным) но все равно, например, даже рассказ о границах можно было бы схематически нарисовать - так было бы понятнее тем, кто не поймет о чем речь...
Слишком много фанатства, чтобы начать работать с технологией нужно смотреть Ulbi и не тратить время ни на что другое. Чтобы попробовать чуть подробнее разобраться в теме - Соера, тут каждый выбирает для себя
Soer, огонь видео для меня, как новичка в этом деле. Всё понятно и интересно было. Благодарю! и не понимаю, куда ещё упрощать...
Для, так сказать, обратной связи у меня опыт программирования 2 года на пхп, тесты никогда не делал, только слышал о них.
Есть что-то такое, что можно порекомендовать какую-то полезную/хорошую литературу или ресурсы/каналы по этому тестированию в целом, помимо документации к фреймворкам?
TDD
хотелось бы ролик про мокки
Объясните кто-нибудь пожалуйста, я так и не понял смысл beforeEach и afterEach, гуглил информацию, но мои тесты корректно работают и без before/after
они точно нужны, когда тебе нужно очистить сессии, куки, localStorage и тд между тестами (или записать туда что-либо)
Хотелось бы узнать про доказательства корректности через математические модели и методы!
Зачем же так сложно все объяснять? Такое впечатление, что видео направлено исключительно на других миддл и синьор разработчиков... Проще надо быть... Новичкам это лучше не смотреть. Я бы рекомендовал писать код построчно, объясняя что именно вы пишите и зачем - так было бы гораздо яснее, а не по написанному сразу что-то сверху наваливать :) Мой мозг взорван, и вы очень умный))
Жуть какая! Отложу тему тестирования на неопределённый срок, чтобы не расстраиваться...
Боюсь, что при такой позиции расстраиваться придется в 100 раз чаще из-за кучи ошибок, на исправление которых потратишь намного больше времени
@@Mike-hp3fh console.log() - наше всё!
Ловить баги - этж круче чем рыбалка и охота в одном флаконе! =) А сколько всего нового узнаёшь о своём коде и ЯП в процессе! Мммм! Каеф! =)))
Это что видео двухлетней давности?
У него typescript версии 4.7.3, а он вышел неделю назад
Что у него с глазом?
думал будет глубже видер, по сути аналогичных полно. не понравился материал, слишком упрощено.
Не тратьте время. Это видео трейни минус. Автор рассказывает для чего нужно писать тесты
2022... разбираем классы....👎👎👎👎👎👎👎