Unit тесты в Python. Тестирование кода | Базовый курс. Программирование на Python

[@maximkorolev7343]

Дружище, спасибо большое, всё четко и по делу, ещё и 5 минут.

[@louispython8215]

Боже, ну почему у таких прекрасных видео так мало лайков.. А всякие "Хауди-Хо" набирают по миллиону подписчиков и по 100к лайков...

[@SweetCoder]

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

[@tetrafen]

@@SweetCoder еще бы тебе веб камеру сменить, чтобы качество картинки радовало глаз)

[@SweetCoder]

@@tetrafen выполнено.

[@flyintie]

хауди работает на массу

[@AlternativeMessage-cs6ux]

@@flyintie типа, железо тягает?

[@КонстантинСедельников-л3ю]

Просто волшебно рассказал. Просто отлично!!

[@SweetCoder]

спасибо за отзыв ))

[@blackcat_77]

Спасибо, все очень четко и лаконично.! Почему так мало лайков.

[@SweetCoder]

спасибо за отзыв

[@Rudoku_]

Спасибо за ваш труд

[@SweetCoder]

на здоровье

[@RuchejAlex]

Что? Я на канале "Нежный кодер"? Сразу вспомнил момент из "Полицейской академии", когда двое попали в бар "Голубая устрица".

[@denissavast]

Благодарю за отличный материал, поехал на пикник !

[@AleksandrGrebelnyi]

спасибо. люблю твои видосы, и лёгкий, но острый юмор👍

[@xm4dn355x]

Бро, было бы круто ещё про тестирование БД, Моки и тесты для внешних API ))) А то там уже шкала сложности усвоения документации по unittest мгновенно взлетает по экспоненте)))

[@SweetCoder]

для того чтобы тестировать API нужно сначала научиться писать API. рано или поздно дойдём

[@tema_skakun]

спасибо тебе человек за этот великолепный ролик. подписался)

[@SweetCoder]

на здоровье

[@RayUa]

Ааааа, Кива с Бужанским прям на своих тупых местах!😆 Спасибо!👍👍👍👍

[@SweetCoder]

🙂😉

[@_pointZero_]

Спасибо, очень познавательно!

[@SweetCoder]

на здоровье

[@leosv0]

Отличное познавательное видео!

[@SweetCoder]

спасибо за отзыв

[@fionover9816]

Спасибо за видео :)

[@SweetCoder]

на здоровье

[@PythonDevelopment]

Спасибо большое. Хотелось бы больше материала по тестам, особенно как писать тесты на приложения из жизни

[@asm64]

Чётко объяснил )

[@Daibend]

Ящик пива этому гению!!!

[@SweetCoder]

тому кто придумал unit-тесты? многие его ненавидят ))

[@art61017]

Спасибо!

[@SweetCoder]

на здоровье

[@OleksandrMatviienko]

спасибо

[@SweetCoder]

на здоровье

[@bullcode8406]

Привет! Изучаю Python и соответственно пишу очень много всего разного, от а+а до генераторов с функциями и прочего (пока на стадии генераторов и функций). При тесте задачи постоянно приходится ее перезапускать и вводить разные данные, int, float, str, коллекции и тд. Правильно ли я понял из видео что моих ручных проверок в каждой второй задаче можно избежать написав юниттест? И наверное можно на такой случай написать универсальный тест и просто импортировать его в свои задачи? Спасибо за видео на канале! Я, конечно же подписан, лайкаю и нажал на колокольчик:)

[@SweetCoder]

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

[@bullcode8406]

@@SweetCoder круто. Спасибо большое!

[@GladSpiR]

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

[@Majkirsche]

класс, спасибо

[@SweetCoder]

на здоровье

[@engineer103]

коммент ради продвижения канала

[@РостиславКолодій-н8ч]

Как фреймворк видит методи, которие начинаются на test_?

[@funk6248]

классно, не знал об этом

[@SweetCoder]

о чем именно?

[@funk6248]

@@SweetCoder о юнит тесте

[@SweetCoder]

до этой темы во время обучения доходят не все. а вообще это нормально. знать всё - невозможно.

[@NoName-hi8bv]

genius, ты показал максимально обсосанный пример, то как работает программа должно быть определенно на этапе проектирования приложения, на этапе получения данных от пользователя должна быть проработана предварительная валидация данных. Если приводить примеры тестирования, то можно выделить пару примеров, например тестировать поведение функции, при вводе условно верных данных, например вы пишете фикцию для каких то вычислений, она безумно сложная и занимает 20 строк кода, и выполняется секунд пять, вы её тестируете сопоставляя с заведомо верными данными, но программист B, решает что данная функция является узким местом программы из за частого его вызова программа тратит много времени на вычисления. После внесения корректировок программистом B программа начала работать и правда быстрее, но благодаря тестам может всплыть что она выполняет задачу с ошибкой, например при вводе отрицательных чисел или float или 0. Так что во многом тесты помогают разработчикам быть уверенным что их код работает так как ожидается. Но есть второе применение которое так же очень важное, например для поддержки приложения, мой пример, я написал парсер для загрузки аудиокниг, и через 2 месяца решил скачать себе новую книгу, по итогу загрузчик ложился с ошибкой в о время загрузки, по логам проблема была в модуле async_downloader и если бы не тесты я бы искал проблему там, но благодаря что я заранее на каждый класс написал тесты стало ясно что структура html немного поменялась, и вместо ссылок на аудиофайлы я получал ссылки на картинки. Которые успешно передавались в модуль загрузчик. Так что тесты нужны так же для поиска ошибок в программе после изменений внешних факторов.

[@PROswimming]

Уважаемый блогер, здравствуйте. Объясните пожалуйста, как понять от какого класса мы должны наследовать класс, который мы сейчас задаем? Это в какой-то документации прописано или мы придумывать должны? У вас в данном случае наследуется от класса unitest.Testcase. Не понимаю, откуда вы взяли Testcase? Это модуль в классе unitest? спасибо

[@SweetCoder]

в данном случае нужно знать или посмотреть в документации. в общем случае наследоваться нужно от того класса, функционал которого нужен тебе в твоём наследнике

[@PROswimming]

@@SweetCoder принял, благодарю

[@KovalchykIgor]

Лайк за шутки!)

[@SweetCoder]

да? ну ок )) спасибо

[@sgatrade8719]

ну, теперь можно идти гробить печень)

[@SweetCoder]

да, только осторожно

[@ИванИванов-н9т9ъ]

Красаучег!

[@SweetCoder]

спасибо за отзыв

[@celticrain25]

Это прям как "сам себе QA"

[@SweetCoder]

на самом деле это не отменяет необходимость в специалистах QA, просто немного экономит время разработки

[@kotonotekstudio2388]

Помню точно такой же видос на английском канале смотрел ;)

[@SweetCoder]

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

[@grozoff]

1:37 лайк!

[@Dandi_jr]

кива не глупый. кива уже кандидат наук!))

[@SweetCoder]

да, "глупый" какое-то неподходящее слово. слишком мягкое

[@amerigovespucci1499]

У меня при вводе python -m unittest "название файла".ру, выдает ошибку. Говорит, файл не найдет. Что можно с этим сделать?

[@SweetCoder]

скорее всего дело в названии файла. либо ты запускаешь его не из той папки в которой он находится

[@amerigovespucci1499]

@@SweetCoder Спасибо, разобрался 👌. Путь надо было доуказать

[@drongerman536]

Вопрос, а как ты запускаешь код из консоли атома, или это сторонний плагин? Отпиши если не сложно)

[@SweetCoder]

не сложно. на канале есть видео с обзором подборки плагинов, которые я постоянно использую. плагин называется platformio-ide-terminal и он полностью копирует функционал родной консоли операционной системы. это не единственный вариант, есть и другие. но мне понравился именно этот из-за возможности настройки цветовых схем

[@9_killa]

У меня почему то Ran 0 test in 0.000s. То с чем св'язано?

[@LOGOSTT]

1:35 Бузова и ещё некоторые могут обидеться ;-)

[@SweetCoder]

не могу сказать, что меня это сильно волнует ))

[@СветиславДобромиров]

Доброго. Почему-то тесты по программе из примера: self.assertRaises(TypeError, circle_area, 'df') self.assertRaises(TypeError, circle_area, [12,12]) self.assertRaises(TypeError, circle_area, {"1":"123"}) не выдают ошибку. Однако вот этот тест выдал ошибку. self.assertRaises(TypeError, circle_area, True) Запуск делал до покрытия тестами основного кода.

[@pavelizyumov8389]

не знаю поможет ли тебе это спустя год) в общем не все объекты можно сравнивать с нулем. собственно например массив с int сравнить нельзя и эта операция итак выдаст ошибку TypeError. Поэтому тест выполняется. А вот True - булево значение, его можно сравнить с int (он преобразуется в единицу)

[@АртурАлиев-й4н]

Используйте isinstance() вместо type() %) Урок полезный, спасибо)

[@SweetCoder]

ты абсолютно прав. дурацкая привычка. спасибо за отзыв

[@БендерЗадунайский-щ9ы]

подписался👍

[@SweetCoder]

🤝👍

[@noone-hi6kq]

сЭрвис блеят)))))))

[@SweetCoder]

тут схематично приведена лишь часть сервиса, чтобы проиллюстрировать идею тестирования

[@liho26]

а в чем разница между unittest и pytest, например?

[@SweetCoder]

а что по этому поводу говорит гугл?

[@liho26]

​@@SweetCoder Много бестолкового. Хотелось бы получить выжимку и краткое объяснение. желательно в видео.

[@SweetCoder]

@@liho26 возможно когда-то дойдут руки и до сравнения тестировочных модулей

[@liho26]

@@SweetCoder Договорились. Когда руки дойдут, тогда на одного подписчика станет больше на этом канале.

[@rockkley9159]

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

[@mRelby13]

Это можно назвать проще: проверка на дурака)) Правда, не совсем понял, зачем юзать доп. модуль, создавать файл и тд... когда всё тоже самое можно проверить в написанной программе, используя для этого if-ы.

[@SweetCoder]

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

[@stanislav1125]

🤦

[@ЮрийАндреевич-т8д]

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

[@SweetCoder]

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

[@ЮрийАндреевич-т8д]

@@SweetCoder потому и "спорно", что это не аксиома : ) Python язык динамически типизированный, направленный на улучшение читаемости кода. Конструкции проверки типов в начале функции удлиняют код и снижают его читаемость, хотя бы фактом своего присутствия, что протеворечит смыслу языка. Не логичнее ли тогда просто писать на статически типизированном языке, где это по умолчанию включено? Чтобы некорректный аргумент не передавать в функцию сейчас присутствуют аннотации типов, но даже они не бросают исключения при несоответствии типов, а служат лишь комментарием для разработчика. Вообще, пользователь же не будет напрямую вызывать функции вашего кода, а делать это через gui или api. Вот на этом уровне и должны отсекаться все подобные неожиданности, и просто не должно быть по умолчанию такой ситуации, что в функцию передан некорректный аргумент. Но кстати, если вы хотите таки использовать проверки типов, могу предложить конструкцию "assert isinstance(radius, float)". Согласитесь, так короче и понятнее конструкций типа "if... raise..."?)

[@SweetCoder]

вот тут я вообще не могу ни с чем согласиться. Тот факт что Python направлен на улучшение читаемости кода совершенно не означает, что в Python не нужно отлавливать исключения и предупреждать нештатные случаи выполнения программы. Если бы это противоречило духу языка не были бы реализованы try ... except и прочие TypeError. "Не логичнее ли писать на статически типизированном языке?" - нет, не логичнее отсекать все неожиданности на уровне GUI не всегда представляется возможным. А на уровне API всё равно придётся проводить проверку соответствия типов. или там тоже нужно пожертвовать проверкой ради легкочитаемости реализации API ? "не должно быть по-умолчанию такой ситуации, что в функцию передан некорректный аргумент" - такое бывает только в стране эльфов и единорогов. у них как-то получается. у нас, простых смертных - нет. assert isinstance(radius, float) - не является приемлемой практикой даже в этом отдельно взятом примерчике. данные могут быть некорректными по двум осям (либо не числовой тип, либо числовой, но число отрицательное или комплексное) для логирования гораздо удобнее иметь информацию о том, произошла TypeError или ValueError, вместо того, чтобы лог был забит исключительно AssertionError

[@ЮрийАндреевич-т8д]

@@SweetCoder "assert isinstance(radius, float) assert radius > 0" В чем проблема то? Конечно ошибки отлавливать нужно, но это не тот случай. Ведь ошибка и без дополнительной проверки выбрасывается в этом примере, и в чем смысл лишней логики тогда. P.S. к assert можно добавить комментарий вторым аргументом. А api или gui это пример. Короче, где угодно кроме самой функции это лучше обрабатывать.

[@SweetCoder]

@@ЮрийАндреевич-т8д я ж написал в чём проблема. AssertionError не даёт классификации того, что именно пошло не так. разные исключения (TypeError, ValueError, etc.) могут обрабатывать по-разному. именно поэтому assert не является Best Practice. Идентифицировать исключения по кастомным "сообщениям" - это, я извиняюсь, детский сад. что дальше? для описания индивидуальной обработки разных исключений будем использовать switch ?

[@ViacheslavHudzovskyi]

up

[@testingcoder]

Популяризация написания юнит тестов - дело хорошее и нужное. Но (ИМО), без TDD теряется до 70% профита от юнит тестов.

[@SweetCoder]

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

[@testingcoder]

@@SweetCoder я думаю нам есть смысл сделать совместное видео на тему. TDD - это это один из спобов делать Unit тестирование :) И кстати, это как раз не про тестирование (поэтому и называется test-driven DEVELOPMENT) Вот тут кстати неплохой пример TDD kzbin.info/www/bejne/hIi9eZaghq9petU

[@Gigantovod]

Похоже тема поживее пошла, тут уже комменты подгребают... Даёшь 100 000 лайков и 100 500 комментов!

[@SweetCoder]

всё будет. вот так по зёрнышку...

[@МихаилКорнюшенко-ж3ы]

АХАХАХАХ ЗА дегтярева в списке глупых отдельный плюс!))

[@dackbird2431]

как на пайтон тестить допустим c# код??

[@SweetCoder]

такое возможно только используя специальные интерфейсы, например браузер или API

[@magictime8959]

"Нежный" кодер

[@андрейхоменко-и5я]

Нифига не понял)))

[@SweetCoder]

значит еще не настало твоё время ))

[@Anshegar]

Принты всера вно лучше и удобней ))))))))))

[@dmytrokovalov2199]

Серьезно? kzbin.info/www/bejne/Z33Jp2iqiqympJo&ab_channel=Socratica

[@SweetCoder]

ну да ))

[@pokupki29]

@@SweetCoder первоисточник круче )

[@semimaks]

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

[@waydaysay]

Я не совсем понял хотя посмотрел его несколько раз

[@izzzanaaami]

как программисты могут пить алкоголь. мне кажется, это негативно влияет не только на печени, но и на мозге

[@kuaranir2440]

А смысл писать Юнит-тесты, если тебе все равно придётся прописывать в своем коде те же условия, из-за которых провален Юнит-тест? А откуда ты вообще берешь критерии для Юнит теста?? То есть суть Юнит теста такова: Я конструирую супер-прочный телефон. Делаю сначала говно, иду тестить его путем бросания на асфальт. Он естественно разбивается. И я такой: "ага, надо сделать ударопрочный корпус". А почему бы мне тогда сразу не делать ударопрочный корпус, лол

[@ИвфИвф]

Действительно, условия и логика должны быть прописаны в ТЗ. В данном случае, почему результат не может быть нулевым или отрицательным? Из приведенного автором видео примера польза юнит-тестирования нулевая и смысл этих тестов не понятен.

[@kuaranir2440]

@@ИвфИвф и я о том же

[@sg6630]

йад

[@SweetCoder]

не понятно

[@sg6630]

@@SweetCoder все понятно. Хорошо рассказываешь.

[@SweetCoder]

@@sg6630 ок. спасибо за отзыв.

[@sg6630]

@@SweetCoder спасибо за видосы! Я учусь кодить и твой материал помогает! Удачи тебе!

[@SweetCoder]

@@sg6630 приятно слышать. желаю успехов!

[@masterprotocol]

ты настолько много куришь что даже через видео запах идёт голимый

[@vinkmelon]

ты зачем такле говориш?

[@АлександрВикторович-и8ы]

Кива ввёл отрицательный радиус

[@annamur6143]

Спасибо!!!

[@SweetCoder]

на здоровье