как проверить код в питоне

Python syntax checker

Python code

Python checker allows to check your Python code syntax (Python 3), and find Python errors. This Python code checker tool highlights and goes to line with a syntax error.

To check your code, you must copy and paste, drag and drop a Python file or directly type in the Online Python editor below, and click on «Check Python syntax» button.

You can see the user guide to help you to use this python checker tool.

User guide

It is quick and easy to analyze python code!

Python code checker tool

Python is a server-side scripting language, but can also be used as a general-purpose programming language.

Python error checker tool allows to find syntax errors (lint). You can test your Python code online directly in your browser.

If a syntax error is detected, then the line in error is highlighted, and it jumps to it to save time (no need to search the line).

Note: This tool no longer offers sandbox, it was not good enough.

About Python

Python is an interpreted programming language, it features a dynamic type system and automatic memory management (garbage collector). Python is available for many operating systems.It has a large standard library.

Python formatting is visually uncluttered, and often uses English keywords rather than punctuation. Python uses whitespace indentation instead of curly brackets to delimit blocks.

Python is often used as a programming language in high school and higher education, especially in France (I am French).

Источник

Анализ кода в Python

Анализ кода в Python может быть трудной темой, но очень полезной в тех случаях, когда вам нужно повысить производительность вашей программы. Существует несколько анализаторов кода для Python, которые вы можете использовать для проверки своего кода и выяснить, соответствует ли он стандартам. Самым популярным можно назвать pylint. Он очень удобен в настойках и подключениях. Он также проверяет ваш код на соответствие с PEP8, официальным руководством по стилю ядра Python, а также ищет программные ошибки. Обратите внимание на то, что pylint проверяет ваш код на большую часть стандартов PEP8, но не на все. Также мы уделим наше внимание тому, чтобы научиться работать с другим анализатором кода, а именно pyflakes.

Начнем с pylint

Пакет pylint не входит в Python, так что вам нужно будет посетить PyPI (Python Package Index), или непосредственно сайт пакета для загрузки. Вы можете использовать следующую команду, которая сделает всю работу за вас:

Если все идет по плану, то pylint установится, и мы сможем пойти дальше.

Анализ вашего кода

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

Теперь нам нужен какой-нибудь код для анализа. Вот часть кода, которая содержит четыре ошибки. Сохраните её в файле под названием crummy_code.py:

Можете увидеть ошибки не запуская код? Давайте посмотрим, может ли pylint найти их!

Есть вопросы по Python?

На нашем форуме вы можете задать любой вопрос и получить ответ от всего нашего сообщества!

Telegram Чат & Канал

Вступите в наш дружный чат по Python и начните общение с единомышленниками! Станьте частью большого сообщества!

Паблик VK

Одно из самых больших сообществ по Python в социальной сети ВК. Видео уроки и книги для вас!

После запуска этой команды вы увидите большую выдачу на вашем экране. Вот частичный пример:

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

Наш pylint нашел 3 ошибки, 4 проблемы с конвенцией, 2 строки, которые нуждаются в рефакторинге и одно предупреждение. Предупреждение и 3 ошибки – это как раз то, что я искал. Мы попытаемся исправить этот код и устранить ряд проблем. Для начала мы наведем порядок в импортах, и изменить функцию getWeight на get_weight, в связи с тем, что camelCase не используется в названиях методов. Нам также нужно исправить вызов get_weight, чтобы он передавал правильное количество аргументов и исправить его, чтобы “self” выступал в качестве первого аргумента. Взглянем на новый код:

Давайте запустим новый код с pylint и посмотрим, насколько успешно мы провели работу. Для краткости, мы еще раз рассмотрим первую часть:

Как мы видим, это очень помогло. Если мы добавим docstrings, мы можем снизить количество ошибок вдвое. Теперь мы готовы перейти к pyflakes!

Работаем с pyflakes

Проект pyflakes это часть чего-то, что называется Divmod Project. Pyflakes на самом деле не выполняет проверяемый код также, как и pylint. Вы можете установить pyflakes при помощи pip, easy_install, или из другого источника.

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

Мы начнем с запуска pyflakes в изначальной версии той же части кода, которую мы использовали для проверки pylint. Вот и он:

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

Несмотря на суперски быструю скорость возврата выдачи, pyflakes не нашел все ошибки. Вызов метода getWeight передает слишком много аргументов, также метод getWeight сам по себе определен некорректно, так как у него нет аргумента self. Что-же, вы, собственно, можете называть первый аргумент так, как вам угодно, но в конвенции он всегда называется self. Если вы исправили код, оперируя тем, что вам сказал pyflakes, код не заработает, несмотря на это.

Подведем итоги

Следующим шагом должна быть попытка запуска pylint и pyflakes в вашем собственном коде, либо же в пакете Python, вроде SQLAlchemy, после чего следует изучить полученные в выдаче данные. Вы можете многое узнать о своем коде, используя данные инструменты. pylint интегрирован с Wingware, Editra, и PyDev. Некоторые предупреждения pylint могут показаться вам раздражительными, или не особо уместными. Существует несколько способов избавиться от таких моментов, как предупреждения об устаревании, через опции командной строки. Вы также можете использовать -generate-rcfile для создания примера файла config, который поможет вам контролировать работу pylint. Обратите внимание на то, что pylint и pyflakes не импортируют ваш код, так что вам не нужно беспокоиться о нежелательных побочных эффектах.

Являюсь администратором нескольких порталов по обучению языков программирования Python, Golang и Kotlin. В составе небольшой команды единомышленников, мы занимаемся популяризацией языков программирования на русскоязычную аудиторию. Большая часть статей была адаптирована нами на русский язык и распространяется бесплатно.

E-mail: vasile.buldumac@ati.utm.md

Образование
Universitatea Tehnică a Moldovei (utm.md)

Источник

Линтеры в Python

В сообществе Python, как и в любой другой группе людей, существует некое коллективное знание. Множество людей прошлось по всем возможным граблям и получило опыт через набитые шишки. Затем через какое-то время, благодаря выступлениям на конференциях, официальным заявлениям, документам, статьям в блогах, код-ревью и личному общению, это знание стало коллективным. Теперь мы просто называем его “хорошими практиками”.

К таким хорошим практикам можно отнести, например, следующие.

Соблюдать (и даже просто помнить) все хорошие практики — не самая простая задача. Зачастую люди плохо справляются с тем, чтобы отсчитывать пробелы и контролировать переменные, и вообще склонны допускать ошибки по невнимательности. Таковы люди, ничего не поделаешь. Машины, наоборот, прекрасно справляются с такими хорошо определёнными задачами, поэтому появились инструменты, которые контролируют следование хорошим практикам.

В компилируемых языках ещё на этапе компиляции программист может получить по щщам первый полезный фидбэк о написанном коде. Компилятор проверит, что код валиден и может быть скомпилирован, а также может выдать предупреждения и рекомендации, как сделать код лучше или читаемее. Т.к. Python является интерпретируемым языком, где этап компиляции как таковой отсутствует, линтеры особенно полезны. На самом деле, это очень важно и круто — узнать, что твой код как минимум является валидным Python-кодом, даже не запуская его.

В этом посте я рассмотрю два самых популярных линтера для Python:

Термин “lint” впервые начал использоваться в таком значении в 1979 году. Так называлась программа для статического анализа кода на C, которая предупреждала об использовании непортабельных на другие архитектуры языковых конструкций. С тех пор “линтерами” называют любые статические анализаторы кода, которые помогают находить распространённые ошибки, делать его однообразным и более читаемым. А названо оно «lint» в честь вот такой штуки:

flake8

Установка

Источник

Путь к проверке типов 4 миллионов строк Python-кода. Часть 1

Сегодня мы предлагаем вашему вниманию первую часть перевода материала о том, как в Dropbox занимаются контролем типов Python-кода.

В Dropbox много пишут на Python. Это — язык, который мы используем чрезвычайно широко — как для бэкенд-сервисов, так и для настольных клиентских приложений. Ещё мы в больших объёмах применяем Go, TypeScript и Rust, но Python — это наш главный язык. Если учитывать наши масштабы, а речь идёт о миллионах строк Python-кода, оказалось, что динамическая типизация такого кода неоправданно усложнила его понимание и начала серьёзно влиять на продуктивность труда. Для смягчения этой проблемы мы приступили к постепенному переводу нашего кода на статическую проверку типов с использованием mypy. Это, вероятно, самая популярная самостоятельная система проверки типов для Python. Mypy — это опенсорсный проект, его основные разработчики трудятся в Dropbox.

Dropbox оказалась одной из первых компаний, которая внедрила статическую проверку типов в Python-коде в подобном масштабе. В наши дни mypy используется в тысячах проектов. Этот инструмент бесчисленное количество раз, что называется, «проверен в бою». Нам, для того, чтобы добраться туда, где мы находимся сейчас, пришлось проделать долгий путь. На этом пути было немало неудачных начинаний и провалившихся экспериментов. Этот материал повествует об истории статической проверки типов в Python — с самого её непростого начала, которое было частью моего научного исследовательского проекта, до сегодняшнего дня, когда проверки типов и подсказки по типам стали привычными для бесчисленного количества разработчиков, которые пишут на Python. Эти механизмы теперь поддерживаются множеством инструментов — таких, как IDE и анализаторы кода.

Зачем нужна проверка типов?

Если вы когда-нибудь пользовались динамически типизированным Python — у вас может возникнуть некоторое непонимание того, почему вокруг статической типизации и mypy в последнее время поднялся такой шум. А может быть и так, что Python вам нравится именно из-за его динамической типизации, а происходящее попросту вас расстраивает. Ключ к ценности статической типизации — это масштаб решений: чем больше ваш проект — тем сильнее вы склоняетесь к статической типизации, и, в конце концов, тем сильнее вам это по-настоящему нужно.

Предположим, некий проект достиг размеров в десятки тысяч строк, и оказалось, что над ним работают несколько программистов. Рассматривая подобный проект мы, основываясь на нашем опыте, можем сказать, что понимание его кода станет ключом к поддержке продуктивности разработчиков. Без аннотаций типов непросто бывает выяснить, например, то, какие аргументы нужно передать функции, или то, значения каких типов может некая функция возвращать. Вот типичные вопросы, на которые часто нелегко бывает ответить без применения аннотаций типов:

Хотя Python отлично показывает себя на ранних или промежуточных стадиях проектов, в определённый момент успешные проекты и компании, которые используют Python, могут столкнуться с жизненно важным вопросом: «Нужно ли нам переписать всё на статически типизированном языке?».

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

У применения подобных систем есть и другие преимущества, и они уже совершенно нетривиальны:

Предыстория mypy

История mypy началась в Великобритании, в Кембридже, за несколько лет до того, как я присоединился к Dropbox. Я занимался, в рамках проведения докторского исследования, вопросом унификации статически типизированных и динамических языков. Меня вдохновляла статья о постепенной типизации Джереми Сиека и Валида Таха, а так же проект Typed Racket. Я пытался найти способы использования одного и того же языка программирования для различных проектов — от маленьких скриптов, до кодовых баз, состоящих из многих миллионов строк. При этом мне хотелось, чтобы в проекте любого масштаба не пришлось бы идти на слишком большие компромиссы. Важной частью всего этого была идея о постепенном переходе от нетипизированного прототипа проекта к всесторонне протестированному статически типизированному готовому продукту. В наши дни эти идеи, в значительной степени, принимаются как должное, но в 2010 году это была проблема, которую всё ещё активно исследовали.

Моя изначальная работа в области проверки типов не была нацелена на Python. Вместо него я использовал маленький «самодельный» язык Alore. Вот пример, который позволит вам понять — о чём идёт речь (аннотации типов здесь необязательны):

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

Моё средство проверки типов для Alore выглядело весьма многообещающим, но мне хотелось проверить его, выполнив эксперименты с реальным кодом, которого, можно сказать, на Alore написано не было. К моему счастью, язык Alore в значительной степени был основан на тех же идеях, что и Python. Было достаточно просто переделать средство для проверки типов так, чтобы оно могло бы работать с синтаксисом и семантикой Python. Это позволило попробовать выполнить проверку типов в опенсорсном Python-коде. Кроме того, я написал транспайлер для преобразования кода, написанного на Alore в Python-код и использовал его для трансляции кода моего средства для проверки типов. Теперь у меня была система для проверки типов, написанная на Python, которая поддерживала подмножество Python, некую разновидность этого языка! (Определённые архитектурные решения, которые имели смысл для Alore, плохо подходили для Python, это всё ещё заметно в некоторых частях кодовой базы mypy.)

На самом деле, язык, поддерживаемый моей системой типов, в этот момент не вполне можно было назвать Python: это был вариант Python из-за некоторых ограничений синтаксиса аннотаций типов Python 3.

Выглядело это как смесь Java и Python:

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

Я, в итоге, представил мой проект на конференции PyCon 2013 в Санта-Кларе. Так же я поговорил об этом с Гвидо ван Россумом, с великодушным пожизненным диктатором Python. Он убедил меня отказаться от собственного синтаксиса и придерживаться стандартного синтаксиса Python 3. Python 3 поддерживает аннотации функций, в результате мой пример можно было переписать так, как показано ниже, получив нормальную Python-программу:

Мне понадобилось пойти на некоторые компромиссы (в первую очередь хочу отметить, что я изобрёл собственный синтаксис именно поэтому). В частности, Python 3.3, самая свежая версия языка на тот момент, не поддерживал аннотаций переменных. Я обсудил с Гвидо по электронной почте различные возможности синтаксического оформления подобных аннотаций. Мы решили использовать для переменных комментарии с указанием типов. Это позволяло добиться поставленной цели, но выглядело несколько громоздко (Python 3.6 дал нам более приятный синтаксис):

Комментарии с типами, кроме того, пригодились для поддержки Python 2, в котором нет встроенной поддержки аннотаций типов:

Оказалось, что эти (и другие) компромиссы, на самом деле, не имели особого значения — преимущества статической типизации привели к тому, что пользователи скоро забыли о не вполне идеальном синтаксисе. Так как теперь в Python-коде, в котором контролировались типы, не применялись особые синтаксические конструкции, существующие Python-инструменты и процессы по обработке кода продолжили нормально работать, что значительно облегчило освоение разработчиками нового инструмента.

Гвидо, кроме того, убедил меня присоединиться к Dropbox после того, как я защитил выпускную работу. Тут начинается самое интересное в истории mypy.

Уважаемые читатели! Если вы пользуетесь Python — просим рассказать о том, проекты какого масштаба вы разрабатываете на этом языке.

Источник

Знакомство с тестированием в Python. Ч.1

От нашего стола к вашему. То есть от нашего курса «Разработчик Python», несмотря на стремительно приближающий Новый год, мы подготовили вам интересный перевод о различных методах тестирования в Python.

Это руководство для тех, кто уже написал классное приложение на Python, но еще не писал для
них тесты.

Тестирование в Python — обширная тема с кучей тонкостей, но не обязательно все усложнять. В несколько простых шагов можно создать простые тесты для приложения, постепенно наращивая сложность на их основе.

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

Тестирование Кода

Тестировать код можно разными способами. В этом руководстве вы познакомитесь с методами от наиболее простых до продвинутых.

Автоматизированное vs. Ручное Тестирование

Хорошие новости! Скорее всего вы уже сделали тест, но еще не осознали этого. Помните, как вы впервые запустили приложение и воспользовались им? Вы проверили функции и поэкспериментировали с ними? Такой процесс называется исследовательским тестированием, и он является формой ручного тестирования.

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

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

Звучит безрадостно, верно?

Поэтому нужны автоматические тесты. Автоматическое тестирование — исполнение плана тестирования (части приложения, требующие тестирования, порядок их тестирования и ожидаемые результаты) с помощью скрипта, а не руками человека. В Python уже есть набор инструментов и библиотек, которые помогут создать автоматизированные тесты для вашего приложения. Рассмотрим эти инструменты и библиотеки в нашем туториале.

Модульные Тесты VS. Интеграционные Тесты

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

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

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

Главная сложность интеграционного тестирования возникает, когда интеграционный тест не дает правильный результат. Сложно оценить проблему, не имея возможности изолировать сломанную часть системы. Если фары не зажглись, возможно лампочки сломаны. Или может аккумулятор разряжен? А может проблема в генераторе? Или вообще сбой в компьютере машины?

Современные машины сами оповестят вас о поломке лампочек. Определяется это с помощью модульного теста.

Модульный тест (юнит-тест) — небольшой тест, проверяющий корректность работы отдельного компонента. Модульный тест помогает изолировать поломку и быстрее устранить ее.

Мы поговорили о двух видах тестов:

Значения правильные, поэтому в REPL ничего не будет выведено. Если результат sum() некорректный, будет выдана AssertionError с сообщением “Should be 6” (“Должно быть 6”). Проверим оператор утверждения еще раз, но теперь с некорректными значениями, чтобы получить AssertionError :

Вместо REPL, положите это в новый Python-файл с названием test_sum.py и выполните его снова:

Теперь у вас есть написанный тест-кейс (тестовый случай), утверждение и точка входа (командной строки). Теперь это можно выполнить в командной строке:

Вы видите успешный результат, “Everything passed” (“Все пройдено”).

sum() в Python принимает на вход любой итерируемый в качестве первого аргумента. Вы проверили список. Попробуем протестировать кортеж. Создадим новый файл с названием test_sum_2.py со следующим кодом:

Можно увидеть, как ошибка в коде вызывает ошибку в консоли с информацией, где она произошла, и каким был ожидаемый результат.

Такие тесты подойдут для простой проверки, но что если ошибки есть больше, чем в одном? На помощь приходят исполнители тестов (test runners). Исполнитель тестов — особое приложение, спроектированное для проведение тестов, проверки данных вывода и предоставления инструментов для отладки и диагностики тестов и приложений.

Выбор Исполнителя Тестов

Для Python доступно множество исполнителей тестов. Например, в стандартную библиотеку Python встроен unittest. В этом руководстве, будем использовать тест-кейсы и исполнители тестов unittest. Принципы работы unittest легко адаптируются для других фреймворков. Перечислим самые популярные исполнители тестов:

unittest встроен в стандартную библиотеку Python, начиная с версии 2.1. Вы наверняка столкнетесь с ним в коммерческих приложениях Python и проектах с открытым исходным кодом.
В unittest есть тестовый фреймворк и исполнитель тестов. При написании и исполнении тестов нужно соблюдать некоторые важные требования.

Чтобы превратить ранее написанный пример в тест-кейс unittest, необходимо:

Таким образом, вы выполнили два теста с помощью исполнителя тестов unittest.

Примечание: Если вы пишете тест-кейсы для Python 2 и 3 — будьте осторожны. В версиях Python 2.7 и ниже unittest называется unittest 2. При импорте из unittest вы получите разные версии с разными функциями в Python 2 и Python 3.

Чтобы узнать больше о unittest’ах почитайте unittest документацию.

Со временем, после написания сотни, а то и тысячи тестов для приложения, становится все сложнее понимать и использовать данные вывода unittest.

nose совместим со всеми тестами, написанными с unittest фреймворком, и может заменить его тестовый исполнитель. Разработка nose, как приложения с открытым исходным кодом, стала тормозиться, и был создан nose2. Если вы начинаете с нуля, рекомендуется использовать именно nose2.

Для начала работы с nose2 нужно установить его из PyPl и запустить в командной строке. nose2 попытается найти все тестовые скрипы с test*.py в названии и все тест-кейсы, унаследованные из unittest.TestCase в вашей текущей директории:

pytest поддерживает выполнение тест-кейсов unittest. Но настоящее преимущество pytest — его тест-кейсы. Тест-кейсы pytest — серия функций в Python-файле с test_ в начале названия.

Есть в нем и другие полезные функции:

Вы избавились от TestCase, использования классов и точек входа командной строки.
Больше информации можно найти на Сайте Документации Pytest.

Написание Первого Теста

Объединим все, что мы уже узнали, и вместо встроенной функции sum() протестируем простую реализацию с теми же требованиями.

Структура папок будет выглядеть так:

project/
│
└── my_sum/
└── __init__.py

При использовании __import__() вам не придется превращать папку проекта в пакет, и вы сможете указать имя файла. Это полезно, если имя файла конфликтует с названиями стандартных библиотек пакетов. Например, если math.py конфликтует с math модулем.

Как Структурировать Простой Тест

Перед написанием тестов, нужно решить несколько вопросов:

Код в этом примере:

Как Писать Утверждения

Последний шаг в написании теста — проверка соответствия выходных данных известным значениям. Это называют утверждением (assertion). Существует несколько общих рекомендаций по написанию утверждений:

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

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

Запуск Первого Теста

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

Запуск Исполнителей Тестов

Исполнитель тестов — приложение Python, которое выполняет тестовый код, проверяет утверждения и выдает результаты тестирования в консоли. В конец test.py добавьте этот небольшой фрагмент кода:

Другой способ — использовать командную строку unittest. Попробуем:

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

Вместо предоставления имени модуля, содержащего тесты, можно запросить авто-обнаружение при помощи следующего:

Эта команда будет искать в текущей директории файлы с test*.py в названии, чтобы протестировать их.

Понимание Результатов Тестирование

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

sum() должен принимать на вход другие списки числового типа, например дроби.

К началу кода в файле test.py добавьте выражение для импорта типа Fraction из модуля fractions стандартной библиотеки.

Теперь добавим тест с утверждением, ожидая некорректное значение. В нашем случае, ожидаем, что сумма ¼, ¼ и ⅖ будет равна 1:

В этих выходных данных вы видите следующее:

Запуск тестов из PyCharm

Если вы используете PyCharm IDE, то можете запустить unittest или pytest, выполнив следующие шаги:

Больше информации доступно на сайте PyCharm.

Запуск Тестов из Visual Studio Code

Если вы пользуетесь Microsoft Visual Studio Code IDE, поддержка unittest, nose и pytest уже встроена в плагин Python.

Если он у вас установлен, можно настроить конфигурацию тестов, открыв Command Palette по Ctrl+Shift+P и написав “Python test”. Вы увидите список вариантов:

Выберите Debug All Unit Tests, после чего VSCode отправит запрос для настройки тестового фреймворка. Кликните по шестеренке для выбора исполнителя тестов (unittest) и домашней директории (.).

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

Видим, что тесты выполняются, но некоторые из них провалены.

В следующей части статьи мы рассмотрим тесты для фреймворков, таких как Django и Flask.

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

Источник