Меню

Проверить код пайтон на ошибки

Check your Python code security before your next PR commit and get alerts of critical bugs using our free online Python code checker — powered by Snyk Code.

Sign up for unlimited checks, no credit card required.

How to use the free code checker

Get code security right from your IDE

This free code checker can find critical vulnerabilities and security issues with a click. To take your application security to the next level, we recommend using Snyk Code for free right from your IDE.

Python code security powered by Snyk Code

This free web based Python code checker is powered by Snyk Code. Sign up now to get access to all the features including vulnerability alerts, real time scan results, and actionable fix advice within your IDE.

Learn about Snyk Code

Human-in-the-Loop Python Code Checker

Snyk Code is an expert-curated, AI-powered Python code checker that analyzes your code for security issues, providing actionable advice directly from your IDE to help you fix vulnerabilities quickly.

Real-time

Scan and fix source code in minutes.

Actionable

Fix vulns with dev friendly remediation.

Integrated in IDE

Find vulns early to save time & money.

Ecosystems

Integrates into existing workflow.

More than syntax errors

Comprehensive semantic analysis.

AI powered by people

Modern ML directed by security experts.

In-workflow testing

Automatically scan every PR and repo.

CI/CD security gate

Integrate scans into the build process.

Frequently asked questions

A code checker is automated software that statically analyzes source code and detects potential issues. More specifically, an online code checker performs static analysis to surface issues in code quality and security. Most code checkers provide in-depth insights into why a particular line of code was flagged to help software teams implement coding best practices. These code-level checks often measure the syntax, style, and documentation completeness of source code.

What are the benefits of an AI-powered Python code checker?

An AI-powered Python code checker allows organizations to detect and remediate more complex code issues earlier in the secure software development lifecycle (SSDLC). AI algorithms that have been trained by hundreds of thousands of open source projects to capture symbolic AI rules about possible issues and remediation. By leveraging this learned knowledge from the global open source development community, an AI engine can often detect quality and security issues that may not be caught during peer code reviews or pair programming. That means the efficiency of an AI-powered Python code checker enables developers to fix issues very early — before they reach production and potentially impact end-users.

Why is a Python code checker vital to secure development?

A key part of DevSecOps is shifting left — or detecting and remediating vulnerabilities earlier in the development process. Implementing a Python code checker into your existing continuous integration and continuous delivery (CI/CD) pipeline is one of the most widely accepted best practices. Embedding static analysis into the IDE informs developers of Python vulnerabilities at the earliest possible moment — eliminating Python code security risks at the source.

What is a syntax error in Python?

A Python syntax error is an issue that occurs when Python code is interpreted during execution. Syntax errors are one of three basic types of error, and are almost always fatal because the Python interpreter cannot understand a line of code. Logic errors occur when the code is valid, but the application doesn’t do what the developer intended. Exceptions occur when the Python parser understands a line of code, but the interpreter is unable to execute it during runtime.

Common Python syntax and logical errors

There are a variety of syntax and logical errors, so it’s important to know how to remediate the most common issues that a debugger or code checker may flag. While logical errors aren’t recognized by the Python interpreter, they still prevent the application from performing as the developer originally intended. Here are some tips to avoid some common logical flaws when writing Python code:

  • Remember to invoke a function to start the execution of the program.
  • Check for infinite loops where the program gets stuck in a recurring code block.
  • Use print statements to understand the flow of execution and ensure it’s correct.
  • Avoid complex expressions that make code harder to read and debug.

How to use a Python code checker to improve code quality and security practices

Integrating a Python code checker into the existing developer workflow is a great way to fix code issues earlier, while also helping developers learn about best practices. This can make a significant impact on the quality and security of Python code that developers write going forward. More maintainable code can also improve the customer experience because there are fewer bugs and technical debt to deal with in the future.When it comes to static application security testing (SAST) with a Python code checker, it’s important to choose a developer-first tool that integrates into developer workflows and produces minimal false positives in scan results. A SAST tool also needs to take a comprehensive approach for scanning source code, and be able to combine with linters to check code syntax and style.The most common types of SAST security analysis are:CONFIGURATION:
Ensures that application configuration files are following security best practices and policies.SEMANTIC:
Examines code contextually to estimate what the developer intended, and check whether the code syntax differs.DATA FLOW:
Tracks the flow of data from insecure sources to ensure it’s cleansed before consumption by the Python application.STRUCTURAL:
Determines whether there are inconsistencies with implementing language-specific best practices and cryptographic techniques.The Python code checker you use should also leverage a comprehensive vulnerability database to identify security issues at the code level, as well as known vulnerabilities introduced via open source dependencies.Vulnerability databases help developers stay on top of the latest security exploits as they’re discovered, without spending endless hours researching the current cyber threat landscape. This type of data-driven security works in tandem with threat intelligence to improve the overall security posture of your organization.Finally, detecting Python code security issues is only half the battle. An effective code checker solution will identify flaws, while also giving developers the insights they need to remediate them. This should include the precise source of the issue, and any known publicly available fixes for both security flaws and code anti-patterns.

What is Python code security?

Python code security can be described using the CIA triad — confidentiality, integrity, and availability. The CIA triad is often used as a model for secure systems, and to identify possible vulnerabilities and fixes. Today, applications consist of 80 to 90% open source dependencies. But the remaining 10 to 20% is critical: this code reflects your personal IP, and there is no open source community helping you keep it secure. The best practice is to accept the work of the open source community by scanning and updating software dependencies in your project using scanners like Snyk Open Source — while doing your part by scanning and fixing your code using Snyk Code.Confidentiality
Secure software systems do not disclose information to parties that are not allowed to receive it. That includes malicious external actors as well as unauthorized internal stakeholders.Integrity
Secure software systems make sure that data and processes are not tempered with, destroyed, or altered. Transactions succeed when all sub-transactions succeed, and the stored data does not contradict each other.Availability
A secure system also needs to be able to be used in due time. Blocking a system by overloading parts of it renders the system useless and insecure.

What is Python code quality?

Python code quality is a subjective term, and means something different to every development team. In general, however, the quality of code relates to how closely it follows commonly accepted coding standards and best practices. Here are five frequently used measures of code quality to consider when developers ask, how do I check my Python code?

  1. Reusability

It’s best to write code that’s highly reusable. For example, in object-oriented programming, it’s important to make classes and methods clean and modular, so that code is easier to debug and scale across projects. Restricting access to certain reusable blocks of code through encapsulation can also improve security.

  1. Maintainability

Along with being reusable, it’s important that Python source code is maintainable. As a codebase grows, complexity and technical debt often increase, leading to bugs that are difficult to pinpoint and slow development in the long run. Automated code analysis and peer reviews can ensure that developers are only pushing highly maintainable code into production.

  1. Testability

High-quality Python code should support testing efforts. Along with writing modular code that makes automated testing easier, developers need to prioritize clear and up-to-date documentation. This allows test engineers to more easily understand the purpose of a particular code snippet.

  1. Consistency

Python code should be portable enough that it can run on any development, staging, or production environment without compatibility issues. Docker and other containerization platforms can help ensure Python code and dependencies are consistent across different deployment environments.

  1. Reliability

Software should be designed for reliability from the start. Meaning developers need to proactively prevent technical debt from accruing when they push Python code. Otherwise, software can become less reliable over time and have a decrease in availability, fault tolerance, data integrity, and ability to recover from outages. These lack of reliability can also have a negative impact on the security posture of an application.Perform a semantic check and secure your Python code in your IDE.
Secure your code as you develop. Snyk’s free IDE plugins scan your Python code for vulnerabilities in real-time and provide fix advice.

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

Начнем с pylint

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

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

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

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

c:Python34Scriptspylint

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

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

import sys

class CarClass:

    «»»»»»

    def __init__(self, color, make, model, year):

        «»»Constructor»»»

        self.color = color

        self.make = make

        self.model = model

        self.year = year

        if «Windows» in platform.platform():

            print(«You’re using Windows!»)

        self.weight = self.getWeight(1, 2, 3)

    def getWeight(this):

        «»»»»»

        return «2000 lbs»

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

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

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

Telegram Чат & Канал

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

Паблик VK

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

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

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

c:py101>c:Python34Scriptspylint crummy_code.py

No config file found, using default configuration

************* Module crummy_code

C: 2, 0: Trailing whitespace (trailing-whitespace)

C: 5, 0: Trailing whitespace (trailing-whitespace)

C: 12, 0: Trailing whitespace (trailing-whitespace)

C: 15, 0: Trailing whitespace (trailing-whitespace)

C: 17, 0: Trailing whitespace (trailing-whitespace)

C: 1, 0: Missing module docstring (missing-docstring)

C: 3, 0: Empty class docstring (empty-docstring)

C: 3, 0: Old-style class defined. (old-style-class)

E: 13,24: Undefined variable ‘platform’ (undefined-variable)

E: 16,36: Too many positional arguments for function call (too-many-function-args)

C: 18, 4: Invalid method name «getWeight» (invalid-name)

C: 18, 4: Empty method docstring (empty-docstring)

E: 18, 4: Method should have «self» as first argument (no-self-argument)

R: 18, 4: Method could be a function (no-self-use)

R: 3, 0: Too few public methods (1/2) (too-few-public-methods)

W: 1, 0: Unused import sys (unused-import)

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

  • С – конвенция (convention)
  • R – рефакторинг (refactor)
  • W – предупреждение (warning)
  • E – ошибка (error)

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

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

# crummy_code_fixed.py

import platform

class CarClass:

    «»»»»»

    def __init__(self, color, make, model, year):

        «»»Constructor»»»

        self.color = color

        self.make = make

        self.model = model

        self.year = year

        if «Windows» in platform.platform():

            print(«You’re using Windows!»)

        self.weight = self.get_weight(3)

    def get_weight(self, this):

        «»»»»»

        return «2000 lbs»

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

c:py101>c:Python34Scriptspylint crummy_code_fixed.py

No config file found, using default configuration

************* Module crummy_code_fixed

C: 1,0: Missing docstring

C: 4,0: CarClass: Empty docstring

C: 21,4: CarClass.get_weight: Empty docstring

W: 21,25: CarClass.get_weight: Unused argument ‘this’

R: 21,4: CarClass.get_weight: Method could be a function

R: 4,0: CarClass: Too few public methods (1/2)

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

Работаем с pyflakes

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

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

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

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

import sys

class CarClass:

    «»»»»»

    def __init__(self, color, make, model, year):

        «»»Constructor»»»

        self.color = color

        self.make = make

        self.model = model

        self.year = year

        if «Windows» in platform.platform():

            print(«You’re using Windows!»)

        self.weight = self.getWeight(1, 2, 3)

    def getWeight(this):

        «»»»»»

        return «2000 lbs»

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

c:py101>c:Python34Scriptspyflakes.exe crummy_code.py

crummy_code.py:1: ‘sys’ imported but unused

crummy_code.py:13: undefined name ‘platform’

Несмотря на суперски быструю скорость возврата выдачи, 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)

  • 2014 — 2018 Технический Университет Молдовы, ИТ-Инженер. Тема дипломной работы «Автоматизация покупки и продажи криптовалюты используя технический анализ»
  • 2018 — 2020 Технический Университет Молдовы, Магистр, Магистерская диссертация «Идентификация человека в киберпространстве по фотографии лица»

Линтеры

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

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

  • Форматировать код по PEP8
    — если этого не делать, то другим людям будет намного сложнее понимать
    ваш код; в плохо оформленном коде сложнее увидеть суть,
    потому что мозг постоянно отвлекается на не несущие смысловой нагрузки
    особенности оформления.
  • Не допускать объявленных, но неиспользуемых переменных/функций/импортов
    — опять же, это усложняет восприятие кода; читателю потребуется потратить
    время на то, чтобы осознать, что вот на эту сущность обращать внимания не
    нужно.
  • Писать короткие функции — слишком сложные функции с большим
    количеством ветвлений и циклов тяжело понимать.
  • Не использовать изменяемый объект в качестве значения аргумента
    функции по умолчанию — иначе в результате можно получить
    очень неожиданные эффекты.

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

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

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

  • flake8;
  • pylint.

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

lint roller

flake8

flake8 — это утилита-комбайн, которая органично объединяет в себе несколько
других анализаторов кода (pycodestyle, pyflakes и mccabe), а также
имеет огромную экосистему плагинов, которые могут добавить к стандартной
поставке ещё кучу различных проверок. На данный момент, это самый
популярный линтер для Python-кода. Кроме того, он предельно прост в
настройке и использовании.

Установка

flake8 устанавливается, как и любой другой Python-пакет,
через pip. Внутри виртуального окружения проекта выполните:

Если вы пользуетесь pipenv, то flake8 нужно устанавливать
как dev-зависимость (ведь для работы программы линтер не нужен,
он нужен только для разработчика):

$ pipenv install --dev flake8

Аналогично с poetry:

$ poetry add --dev flake8

Проверим установку:

$ flake8 --version
3.8.1 (mccabe: 0.6.1, pycodestyle: 2.6.0, pyflakes: 2.2.0) CPython 3.8.2 on Linux

Использование

Для работы flake8 нужно просто указать файл или директорию, которые
нужно проверять, например:

# проверить один файл
$ flake8 file.py

# проверить директорию рекурсивно 
$ flake8 src/

# проверить текущую директорию рекурсивно
$ flake8 .

Давайте для демонстрации попытаемся написать программу с как можно большим
количеством “плохих практик”:

Возможно, вам не видно всего, но в этом коде точно есть следующие «запахи кода»:

  • import * — импортирование всех имен из модуля, хотя используется
    из них только одно;
  • import itertools — ненужный импорт;
  • во множестве мест стоят лишние или отсутствующие пробелы;
  • название функции написано в стиле PascalCase;
  • в некоторых местах используются табы для отступов;
  • используется список (изменяемый объект) в качестве значения аргумента
    функции по умолчанию;
  • используется слишком “широкое” выражение except: без указания
    конкретного исключения.

Давайте посмотрим, что flake8 скажет по поводу этого файла:

$ flake8 bad_code.py
bad_code.py:1:1: F403 'from math import *' used; unable to detect undefined names
bad_code.py:2:1: F401 'itertools' imported but unused
bad_code.py:4:1: E302 expected 2 blank lines, found 1
bad_code.py:4:4: E271 multiple spaces after keyword
bad_code.py:4:25: E211 whitespace before '('
bad_code.py:4:33: E202 whitespace before ')'
bad_code.py:5:1: W191 indentation contains tabs
bad_code.py:5:8: E271 multiple spaces after keyword
bad_code.py:5:10: F405 'sqrt' may be undefined, or defined from star imports: math
bad_code.py:5:21: E202 whitespace before ')'
bad_code.py:7:1: E302 expected 2 blank lines, found 1
bad_code.py:7:23: E741 ambiguous variable name 'l'
bad_code.py:8:1: E101 indentation contains mixed spaces and tabs
bad_code.py:9:1: E101 indentation contains mixed spaces and tabs
bad_code.py:11:1: E305 expected 2 blank lines after class or function definition, found 1
bad_code.py:12:1: E101 indentation contains mixed spaces and tabs
bad_code.py:13:1: E101 indentation contains mixed spaces and tabs
bad_code.py:13:20: E225 missing whitespace around operator
bad_code.py:14:1: E101 indentation contains mixed spaces and tabs
bad_code.py:14:67: W291 trailing whitespace
bad_code.py:15:1: E101 indentation contains mixed spaces and tabs
bad_code.py:15:14: W291 trailing whitespace
bad_code.py:16:1: E101 indentation contains mixed spaces and tabs
bad_code.py:16:5: E722 do not use bare 'except'
bad_code.py:17:1: E101 indentation contains mixed spaces and tabs

Как видите, flake8 нашёл кучу ошибок. Для каждой ошибки указана строка
и номер символа в строке (не всегда точный), где произошла ошибка.
Также у каждой категории ошибок есть свой код: E101, W291 и т.д.
Эти коды ошибок могут использоваться для включения/отключения правил.
Тем не менее, не все ошибки были найдены. Давайте установим пару плагинов,
чтобы добавить ещё правил!

Плагины

Как я уже говорил, для flake8 написано множество плагинов.
Обычно плагины легко гуглятся или находятся в списках плагинов.
Есть плагины для всех популярных фреймворков и библиотек — пользуйтесь ими!
Давайте для нашего простого примера установим
flake8-bugbear
(находит распространённые логические ошибки) и
pep8-naming
(проверяет имена на соответствие PEP8).

Плагины устанавливаются так же, как и сам flake8 (для краткости я
не буду писать примеры для pipenv и poetry — сами сможете обобщить):

$ pip install flake8-bugbear pep8-naming

Давайте убедимся, что плагины действительно установились
и flake8 может их найти:

$ flake8 --version
3.8.1 (flake8-bugbear: 20.1.4, mccabe: 0.6.1, naming: 0.10.0, pycodestyle: 2.6.0, pyflakes: 2.2.0) CPython 3.8.2 on Linux

Если вы видите в списке в скобках названия ваших плагинов, то всё хорошо.

Теперь снова проверим наш файл:

$ flake8 bad_code.py
bad_code.py:1:1: F403 'from math import *' used; unable to detect undefined names
bad_code.py:2:1: F401 'itertools' imported but unused
bad_code.py:4:1: E302 expected 2 blank lines, found 1
bad_code.py:4:4: E271 multiple spaces after keyword
bad_code.py:4:6: N802 function name 'CalculateSquareRoot' should be lowercase
bad_code.py:4:25: E211 whitespace before '('
bad_code.py:4:28: N803 argument name 'Number' should be lowercase
bad_code.py:4:33: E202 whitespace before ')'
bad_code.py:5:1: W191 indentation contains tabs
bad_code.py:5:8: E271 multiple spaces after keyword
bad_code.py:5:10: F405 'sqrt' may be undefined, or defined from star imports: math
bad_code.py:5:21: E202 whitespace before ')'
bad_code.py:7:1: E302 expected 2 blank lines, found 1
bad_code.py:7:23: E741 ambiguous variable name 'l'
bad_code.py:7:25: B006 Do not use mutable data structures for argument defaults.  They are created during function definition time. All calls to the function reuse this one instance of that data structure, persisting changes between them.
bad_code.py:8:1: E101 indentation contains mixed spaces and tabs
bad_code.py:9:1: E101 indentation contains mixed spaces and tabs
bad_code.py:11:1: E305 expected 2 blank lines after class or function definition, found 1
bad_code.py:12:1: E101 indentation contains mixed spaces and tabs
bad_code.py:13:1: E101 indentation contains mixed spaces and tabs
bad_code.py:13:20: E225 missing whitespace around operator
bad_code.py:14:1: E101 indentation contains mixed spaces and tabs
bad_code.py:14:67: W291 trailing whitespace
bad_code.py:15:1: E101 indentation contains mixed spaces and tabs
bad_code.py:15:14: W291 trailing whitespace
bad_code.py:16:1: E101 indentation contains mixed spaces and tabs
bad_code.py:16:5: E722 do not use bare 'except'
bad_code.py:16:5: B001 Do not use bare `except:`, it also catches unexpected events like memory errors, interrupts, system exit, and so on.  Prefer `except Exception:`.  If you're sure what you're doing, be explicit and write `except BaseException:`.
bad_code.py:17:1: E101 indentation contains mixed spaces and tabs

В выводе появились новые категории ошибок (N802, B006)
— они как раз добавлены плагинами. На этот раз, как мне кажется,
найдены все ошибки. К сожалению, flake8 не умеет сам чинить
найденные ошибки, поэтому давайте сделаем это вручную:

Обратите внимание на строки 8 и 10, там содержится комментарии # noqa.
При помощи этих комментариев можно заставить flake8 игнорировать ошибки.
Это бывает полезно, когда по какой-то причине код должен остаться именно
таким, например:

  • он автоматически сгенерирован и исправление в нём ошибок не имеет смысла;
  • исправление этой ошибки породит куда более уродливый код,
    чем комментарий # noqa;
  • у вас просто сейчас нет времени, чтобы исправлять эту ошибку
    (плохая отмазка, серьёзно).

Если не указать код ошибки, то будут проигнорированы все ошибки в строке
— я не рекомендую так делать, потому что так можно пропустить
и на самом деле плохие ошибки. Если указать номер правила, то
flake8 будет игнорировать только указанную категорию,
а о других ошибках в этой же строке доложит.
Вообще, комментариями # noqa нужно пользоваться с большой осторожностью.
Считайте, что каждый раз, когда вы это делаете, вы берёте на
себя ответственность за эту строку кода. Если программа сломается
в этом месте, то пеняйте на себя — минздрав линтер вас предупреждал.

Конфигурация

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

[flake8]
ignore = D203,E741
exclude =
    # No need to traverse our git directory
    .git,
    # There's no value in checking cache directories
    __pycache__,
    # The conf file is mostly autogenerated, ignore it
    docs/source/conf.py,
    # The old directory contains Flake8 2.0
    old,
    # This contains our built documentation
    build,
    # This contains builds of flake8 that we don't want to check
    dist
max-complexity = 10

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

Если же вам не хватает какого-нибудь правила, и его нет даже в уже
готовых плагинах, то написание собственного плагина
— не такая уж и сложная задача.
Я попробовал,
у меня на это ушло 2-3 часа.

pylint

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

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

Установка

Установка pylint принципиально ничем не отличается от установки flake8.
Выполнить внутри виртуального окружения проекта:

Для pipenv:

$ pipenv install --dev pylint

Для poetry:

$ poetry add --dev pylint

Использование

pylint можно натравить на определённый файл:

С директориями у pylint дела обстоят чуть сложнее. Все директории он
обрабатывает как питоновские модули, поэтому если в директории нет хотя бы
пустого файла __init__.py, то работать с ней pylint не сможет. Имейте
это ввиду.

Давайте попросим pylint прокомментировать файл с плохими практиками
из предыдущего примера:

$ pylint bad_code.py
************* Module bad_code
bad_code.py:4:25: C0326: No space allowed before bracket
def  CalculateSquareRoot (Number ):
                         ^ (bad-whitespace)
bad_code.py:4:33: C0326: No space allowed before bracket
def  CalculateSquareRoot (Number ):
                                 ^ (bad-whitespace)
bad_code.py:5:0: W0312: Found indentation with tabs instead of spaces (mixed-indentation)
bad_code.py:5:21: C0326: No space allowed before bracket
    return  sqrt(Number )
                     ^ (bad-whitespace)
bad_code.py:13:19: C0326: Exactly one space required around assignment
        your_number=float(input('Enter your number: '))
                   ^ (bad-whitespace)
bad_code.py:14:66: C0303: Trailing whitespace (trailing-whitespace)
bad_code.py:15:13: C0303: Trailing whitespace (trailing-whitespace)
bad_code.py:1:0: W0622: Redefining built-in 'pow' (redefined-builtin)
bad_code.py:1:0: C0114: Missing module docstring (missing-module-docstring)
bad_code.py:1:0: W0401: Wildcard import math (wildcard-import)
bad_code.py:4:0: C0103: Function name "CalculateSquareRoot" doesn't conform to snake_case naming style (invalid-name)
bad_code.py:4:0: C0103: Argument name "Number" doesn't conform to snake_case naming style (invalid-name)
bad_code.py:4:0: C0116: Missing function or method docstring (missing-function-docstring)
bad_code.py:7:0: W0102: Dangerous default value [] as argument (dangerous-default-value)
bad_code.py:7:0: C0103: Argument name "l" doesn't conform to snake_case naming style (invalid-name)
bad_code.py:7:0: C0116: Missing function or method docstring (missing-function-docstring)
bad_code.py:16:4: W0702: No exception type(s) specified (bare-except)
bad_code.py:1:0: W0614: Unused import acos from wildcard import (unused-wildcard-import)
bad_code.py:1:0: W0614: Unused import acosh from wildcard import (unused-wildcard-import)
bad_code.py:1:0: W0614: Unused import asin from wildcard import (unused-wildcard-import)
bad_code.py:1:0: W0614: Unused import asinh from wildcard import (unused-wildcard-import)
...
bad_code.py:2:0: W0611: Unused import itertools (unused-import)
-------------------------------------
Your code has been rated at -41.43/10

Я немного сократил вывод. Как видите, даже без плагинов pylint нашёл
все ожидаемые ошибки, и даже больше — например, он даже предлагает написать
документацию.

По каждой ошибке можно запросить более подробную справку, используя
название правила из конца строки с ошибкой или код:

$ pylint --help-msg=missing-docstring
$ pylint --help-msg=R0902

Вот какие ошибки pylint находит для файла, который с точки зрения flake8
не содержит никаких ошибок:

$ pylint not_so_bad_code.py 
************* Module not_so_bad_code
not_so_bad_code.py:1:0: C0114: Missing module docstring (missing-module-docstring)
not_so_bad_code.py:4:0: C0116: Missing function or method docstring (missing-function-docstring)
not_so_bad_code.py:8:0: C0103: Argument name "l" doesn't conform to snake_case naming style (invalid-name)
not_so_bad_code.py:8:0: C0116: Missing function or method docstring (missing-function-docstring)
not_so_bad_code.py:20:11: W0703: Catching too general exception Exception (broad-except)
-----------------------------------
Your code has been rated at 6.67/10

А вот так в pylint можно игнорировать отдельную ошибку на строке прямо в файлах
с кодом:

def append_item(item, l=None):  # pylint: disable=C0103
   ...

Ещё pylint умеет игнорировать ошибки в блоках кода:

def test():
    # Disable all the no-member violations in this function
    # pylint: disable=no-member
    ...

И для файлов целиком. Вот так можно отключить все ошибки из категорий
Warning, Convention и Refactor:

А можно не проверять файл вообще:

Подробнее о правилах управления сообщениями
смотрите в документации.
Для более сложной настройки правил, придётся по-настоящему сконфигурировать
pylint.

Конфигурация

pylint настраивается через файл .pylintrc в корне проекта. Чтобы создать
дефолтный файл конфигурации, нужно выполнить следующую команду:

$ pylint --generate-rcfile > .pylintrc

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

Плагины

Давайте установим какой-нибудь популярный плагин, например,
pylint-django:

$ pip install pylint-django

Теперь запускать pylint нужно вот так:

$ pylint --load-plugins pylint_django [..other options..] <path_to_your_sources>

либо в .pylintrc нужно исправить директиву load-plugins:

load-plugins=pylint_django

Интеграция линтера в проект

Интегрировать линтер в проект можно на трёх уровнях.
Я рекомендую по возможности использовать все три, но обязательным
является как минимум один (лучше всего, чтобы это была CI система).

Редактор кода или IDE

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

PyCharm автоматически находить установленные flake8 и pylint внутри
интерпретатора проекта
и подключается к ним.

VS Code требует небольшой настройки, которая
описана здесь.

Git-хуки

Также читайте пост про Git-хуки и pre-commit.

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

я запушель

Нас интересует возможность запускать линтер перед коммитом так,
чтобы если линтер найдёт какие-нибудь проблемы, операция коммита прерывалась.
Git-хуки можно настроить, написав несложный shell-скрипт,
но я рекомендую использовать для этого специальные утилиты,
такие как pre-commit.
Вот здесь
можно найти описание процесса настройки запуска flake8 через pre-commit.

Обратите внимание, что Git-хуки нужно будет настроить на машине каждого
разработчика в проекте.

Continuous Integration (CI)

Последний эшелоном защиты от попадания “сломанного” кода в основную ветку
репозитория является система непрерывной интеграции (CI) — такая, как:

  • GitHub Actions;
  • GitLab CI
    (а ещё читайте пост в блоге моего хорошего товарища про
    основы GitLab CI);
  • Travis CI;
  • или другая.

На каждый пуш в репозиторий система непрерывной интеграции должна
запускать проверки (включая все линтеры и тесты), и если что-то идёт
не так, рядом с коммитом должен появиться красный крестик.
Ветку с таким коммитом на конце нельзя будет слить с основной
веткой проекта через пулл-реквест на GitHub (или мёрдж-реквест на GitLab).
Пример того, как настроить GitHub Actions
для запуска flake8 и других питоновских проверок.

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

Заключение

В подзаголовке этой статьи я написал фразу, что линтер способен
сэкономить разработчику один день жизни в месяц. Фраза может показаться
кликбейтной, но, поверьте мне, это так это и работает.
Возможно, я даже преуменьшил.
Чем раньше найдена ошибка, тем быстрее идёт разработка.
Иногда линтер предотвращает баги, иногда спасает от мучительного
траблшутинга. Линтеры абсолютно точно значительно сокращают время,
потраченное коллегами на код-ревью, потому что все тривиальные
ошибки будут отловлены автоматикой.

Не стоит недооценивать линтеры. Это те инструменты,
которые делают из “кодера” настоящего “software engineer”,
из мальчика — мужчину. Если вы до сих пор не пользуетесь каким-нибудь
линтером, то рекомендую всерьез задуматься над внедрением!

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

У pylint тоже есть свои последователи. Его ценят за подробный вывод
и большое количество правил в стандартной поставке.
Мне же pylint всегда казался слишком сложным в эксплуатации.

А кто-то вообще рекомендует устанавливать flake8 и pylint параллельно.

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

Дополнительное чтение

  • документация flake8;
  • исходный код flake8;
  • список плагинов flake8;
  • сайт, где можно посмотреть правила flake8;
  • документация pylint;
  • исходный код pylint;
  • обсуждение “flake8 vs pylint” на Reddit;
  • пост на RealPython про качество кода;
  • статья на Хабре про линтеры.

Обложка: Sa Mu, Traffic Light

python logo

Хочешь знать больше о Python?

Подпишись на наш канал о Python в Telegram!

Подписаться

×

В первой части статьи, опубликованной на pythonist.ru (с которой мы уже знакомили вас ранее), разбиралось, почему качество кода имеет такое большое значение, какой код можно считать качественным и на какие стандарты можно ориентироваться.

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

Для сравнения пропустим одинаковый код через несколько линтеров с дефолтными настройками.

Проверять будем следующий код. В нем есть целый ряд логических и стилистических ошибок:

"""
code_with_lint.py
Example Code with lots of lint!
"""
import io
from math import *


from time import time

some_global_var = 'GLOBAL VAR NAMES SHOULD BE IN ALL_CAPS_WITH_UNDERSCOES'

def multiply(x, y):
    """
    This returns the result of a multiplation of the inputs
    """
    some_global_var = 'this is actually a local variable...'
    result = x* y
    return result
    if result == 777:
        print("jackpot!")

def is_sum_lucky(x, y):
    """This returns a string describing whether or not the sum of input is lucky
    This function first makes sure the inputs are valid and then calculates the
    sum. Then, it will determine a message to return based on whether or not
    that sum should be considered "lucky"
    """
    if x != None:
        if y is not None:
            result = x+y;
            if result == 7:
                return 'a lucky number!'
            else:
                return( 'an unlucky number!')

            return ('just a normal number')

class SomeClass:

    def __init__(self, some_arg,  some_other_arg, verbose = False):
        self.some_other_arg  =  some_other_arg
        self.some_arg        =  some_arg
        list_comprehension = [((100/value)*pi) for value in some_arg if value != 0]
        time = time()
        from datetime import datetime
        date_and_time = datetime.now()
        return

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

ЛИНТЕР КОМАНДА ВРЕМЯ
Pylint pylint code_with_lint.py 1,16 с
PyFlakes pyflakes code_with_lint.py 0,15 с
pycodestyle pycodestyle code_with_lint.py 0,14 с
pydocstyle pydocstyle code_with_lint.py 0,21 с

Теперь давайте посмотрим на результаты.

Pylint

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

Самые распространенные жалобы на Pylint — медленная работа, излишняя многословность по умолчанию и необходимость долго копаться в настройках, чтобы сделать все по своему вкусу. Если отбросить скорость работы, все остальные пункты — палка о двух концах. Многословность объясняется скрупулезностью. Большое количество настроек позволяет подогнать под свои нужды очень многие вещи.

Итак, вот результат запуска Pylint для приведенного выше кода:

No config file found, using default configuration
* Module code_with_lint
W: 23, 0: Unnecessary semicolon (unnecessary-semicolon)
C: 27, 0: Unnecessary parens after 'return' keyword (superfluous-parens)
C: 27, 0: No space allowed after bracket
return( 'an unlucky number!')
^ (bad-whitespace)
C: 29, 0: Unnecessary parens after 'return' keyword (superfluous-parens)
C: 33, 0: Exactly one space required after comma
def init(self, some_arg, some_other_arg, verbose = False):
^ (bad-whitespace)
C: 33, 0: No space allowed around keyword argument assignment
def init(self, some_arg, some_other_arg, verbose = False):
^ (bad-whitespace)
C: 34, 0: Exactly one space required around assignment
self.some_other_arg = some_other_arg
^ (bad-whitespace)
C: 35, 0: Exactly one space required around assignment
self.some_arg = some_arg
^ (bad-whitespace)
C: 40, 0: Final newline missing (missing-final-newline)
W: 6, 0: Redefining built-in 'pow' (redefined-builtin)
W: 6, 0: Wildcard import math (wildcard-import)
C: 11, 0: Constant name "some_global_var" doesn't conform to UPPER_CASE naming style (invalid-name)
C: 13, 0: Argument name "x" doesn't conform to snake_case naming style (invalid-name)
C: 13, 0: Argument name "y" doesn't conform to snake_case naming style (invalid-name)
C: 13, 0: Missing function docstring (missing-docstring)
W: 14, 4: Redefining name 'some_global_var' from outer scope (line 11) (redefined-outer-name)
W: 17, 4: Unreachable code (unreachable)
W: 14, 4: Unused variable 'some_global_var' (unused-variable)
…
R: 24,12: Unnecessary "else" after "return" (no-else-return)
R: 20, 0: Either all return statements in a function should return an expression, or none of them should. (inconsistent-return-statements)
C: 31, 0: Missing class docstring (missing-docstring)
W: 37, 8: Redefining name 'time' from outer scope (line 9) (redefined-outer-name)
E: 37,15: Using variable 'time' before assignment (used-before-assignment)
W: 33,50: Unused argument 'verbose' (unused-argument)
W: 36, 8: Unused variable 'list_comprehension' (unused-variable)
W: 39, 8: Unused variable 'date_and_time' (unused-variable)
R: 31, 0: Too few public methods (0/2) (too-few-public-methods)
W: 5, 0: Unused import io (unused-import)
W: 6, 0: Unused import acos from wildcard import (unused-wildcard-import)
…
W: 9, 0: Unused time imported from time (unused-import)

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

Обратите внимание, что Pylint добавляет к каждой проблемной области префикс R, C, W, E или F, что означает:

  • [R]efactor — нужен рефакторинг, поскольку показатель «good practice» не на должном уровне.
  • [C]onvention — нарушение соглашения о стандарте кода
  • [W]arning — предупреждение о стилистических проблемах или минорных программных проблемах
  • [E]rror — существенные проблемы в программе (скорее всего баг)
  • [F]atal — ошибки, мешающие дальнейшей работе.

Приведенный список — из пользовательского руководства Pylint.

PyFlakes

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

Преимущество этого инструмента в скорости. PyFlakes обработал файл лишь за небольшую долю времени, которое потребовалось Pylint.

Вывод после запуска Pyflakes для приведенного выше кода:

code_with_lint.py:5: 'io' imported but unused
code_with_lint.py:6: 'from math import *' used; unable to detect undefined names
code_with_lint.py:14: local variable 'some_global_var' is assigned to but never used
code_with_lint.py:36: 'pi' may be undefined, or defined from star imports: math
code_with_lint.py:36: local variable 'list_comprehension' is assigned to but never used
code_with_lint.py:37: local variable 'time' (defined in enclosing scope on line 9) referenced before assignment
code_with_lint.py:37: local variable 'time' is assigned to but never used
code_with_lint.py:39: local variable 'date_and_time' is assigned to but never used

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

pycodestyle (прежде — pep8)

Этот инструмент проверяет код на соответствие некоторым соглашениям из PEP 8. Нейминг не проверяется, так же как и docstrings. Ошибки и предупреждения, выдаваемые этим инструментом, можно посмотреть в таблице.

Результат использования pycodestyle для приведенного выше кода:

code_with_lint.py:13:1: E302 expected 2 blank lines, found 1
code_with_lint.py:15:15: E225 missing whitespace around operator
code_with_lint.py:20:1: E302 expected 2 blank lines, found 1
code_with_lint.py:21:10: E711 comparison to None should be 'if cond is not None:'
code_with_lint.py:23:25: E703 statement ends with a semicolon
code_with_lint.py:27:24: E201 whitespace after '('
code_with_lint.py:31:1: E302 expected 2 blank lines, found 1
code_with_lint.py:33:58: E251 unexpected spaces around keyword / parameter equals
code_with_lint.py:33:60: E251 unexpected spaces around keyword / parameter equals
code_with_lint.py:34:28: E221 multiple spaces before operator
code_with_lint.py:34:31: E222 multiple spaces after operator
code_with_lint.py:35:22: E221 multiple spaces before operator
code_with_lint.py:35:31: E222 multiple spaces after operator
code_with_lint.py:36:80: E501 line too long (83 > 79 characters)
code_with_lint.py:40:15: W292 no newline at end of file

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

pydocstyle (прежде — pep257)

Этот инструмент очень похож на предыдущий, pycodestyle, за исключением того, что проверяет код не на соответствие PEP 8, а на соответствие PEP 257.

Результат запуска для приведенного выше кода:

code_with_lint.py:1 at module level:
         D200: One-line docstring should fit on one line with quotes (found 3)
 code_with_lint.py:1 at module level:
         D400: First line should end with a period (not '!')
 code_with_lint.py:13 in public function `multiply`:
         D103: Missing docstring in public function
 code_with_lint.py:20 in public function `is_sum_lucky`:
         D103: Missing docstring in public function
 code_with_lint.py:31 in public class `SomeClass`:
         D101: Missing docstring in public class
 code_with_lint.py:33 in public method `__init__`:
         D107: Missing docstring in __init__

Как и pycodestyle, pydocstyle помечает и разбивает по категориям найденные ошибки. Этот список не конфликтует ни с чем из pycodestyle, поскольку все ошибки имеют приставку D (означающую docstring). Список ошибок можно посмотреть здесь.

Код без ошибок

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

"""Example Code with less lint."""

from math import pi
from time import time
from datetime import datetime

SOME_GLOBAL_VAR = 'GLOBAL VAR NAMES SHOULD BE IN ALL_CAPS_WITH_UNDERSCOES'


def multiply(first_value, second_value):
    """Return the result of a multiplation of the inputs."""
    result = first_value * second_value

    if result == 777:
        print("jackpot!")

    return result


def is_sum_lucky(first_value, second_value):
    """
    Return a string describing whether or not the sum of input is lucky.

    This function first makes sure the inputs are valid and then calculates the
    sum. Then, it will determine a message to return based on whether or not
    that sum should be considered "lucky".
    """
    if first_value is not None and second_value is not None:
        result = first_value + second_value
        if result == 7:
            message = 'a lucky number!'
        else:
            message = 'an unlucky number!'
    else:
        message = 'an unknown number! Could not calculate sum...'

    return message


class SomeClass:
    """Is a class docstring."""

    def __init__(self, some_arg, some_other_arg):
        """Initialize an instance of SomeClass."""
        self.some_other_arg = some_other_arg
        self.some_arg = some_arg
        list_comprehension = [
            ((100/value)*pi)
            for value in some_arg
            if value != 0
        ]
        current_time = time()
        date_and_time = datetime.now()
        print(f'created SomeClass instance at unix time: {current_time}')
        print(f'datetime: {date_and_time}')
        print(f'some calculated values: {list_comprehension}')

    def some_public_method(self):
        """Is a method docstring."""
        pass

    def some_other_public_method(self):
        """Is a method docstring."""
        pass

Согласно «мнению» приведенных выше линтеров, этот код больше не имеет «ворсинок». И хотя логика сама по себе бессмысленная, вы можете заметить, что, как минимум, этот код отличается единообразием.

В рассмотренном случае мы запускали линтеры на уже написанном коде. Но это не единственный способ проверки качества кода.

Когда можно проверять качество кода?

Вы можете проверять качество своего кода:

  • по мере написания,
  • перед отправкой,
  • при запуске тестов.

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

Чтобы этого избежать, проверяйте качество кода почаще!

Проверка кода по мере его написания

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

По ссылкам вы сможете найти полезную информацию по этой теме для разных редакторов:

  • Sublime Text
  • VS Code
  • Atom
  • Vim
  • Emacs

Проверка кода перед его отправкой

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

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

При запуске тестов

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

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

Заключение

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

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

Благодаря руководствам по стилю ваш код может стать единообразным. PEP8 — отличная отправная точка, если речь идет о Python. Линтеры помогут вам обнаружить проблемные места и стилевые несоответствия. Использовать эти инструменты можно на любой стадии процесса разработки; их можно даже автоматизировать, чтобы код с «пухом» не прошел слишком далеко.

Использование линтеров позволяет избежать ненужных дискуссий о стиле в ходе код-ревью. Некоторым людям морально легче получить объективный фидбэк от инструментов, а не от товарищей по команде. Кроме того, некоторые ревьюеры могут просто не хотеть «придираться» к стилю проверяемого кода. Линтеры не озабочены всеми этими политесами и экономией времени: они жалуются на любое несоответствие.

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

Улучшение качества кода это процесс. Вы можете предпринимать некоторые шаги в этом направлении и не выбрасывая весь несоответствующий стандарту код. Осведомленность — прекрасный первый шаг. Чтобы его сделать, нужно только осознать, насколько важно поддерживать высокое качество кода.

I used to use perl -c programfile to check the syntax of a Perl program and then exit without executing it. Is there an equivalent way to do this for a Python script?

Koterpillar's user avatar

Koterpillar

7,7422 gold badges26 silver badges41 bronze badges

asked Nov 26, 2010 at 10:12

Eugene Yarmash's user avatar

Eugene YarmashEugene Yarmash

138k39 gold badges318 silver badges372 bronze badges

0

You can check the syntax by compiling it:

python -m py_compile script.py

Daniel Fischer's user avatar

answered Dec 8, 2011 at 20:57

Mark Johnson's user avatar

15

import sys
filename = sys.argv[1]
source = open(filename, 'r').read() + 'n'
compile(source, filename, 'exec')

Save this as checker.py and run python checker.py yourpyfile.py.

rvighne's user avatar

rvighne

20.1k11 gold badges51 silver badges73 bronze badges

answered Nov 26, 2010 at 10:39

Rosh Oxymoron's user avatar

Rosh OxymoronRosh Oxymoron

20k6 gold badges41 silver badges43 bronze badges

3

Here’s another solution, using the ast module:

python -c "import ast; ast.parse(open('programfile').read())"

To do it cleanly from within a Python script:

import ast, traceback

filename = 'programfile'
with open(filename) as f:
    source = f.read()
valid = True
try:
    ast.parse(source)
except SyntaxError:
    valid = False
    traceback.print_exc()  # Remove to silence any errros
print(valid)

answered Aug 15, 2019 at 11:15

jmd_dk's user avatar

jmd_dkjmd_dk

11.5k8 gold badges65 silver badges92 bronze badges

5

Pyflakes does what you ask, it just checks the syntax. From the docs:

Pyflakes makes a simple promise: it will never complain about style, and it will try very, very hard to never emit false positives.

Pyflakes is also faster than Pylint or Pychecker. This is largely because Pyflakes only examines the syntax tree of each file individually.

To install and use:

$ pip install pyflakes
$ pyflakes yourPyFile.py

answered Jan 8, 2020 at 19:52

Brian C.'s user avatar

Brian C.Brian C.

5,6773 gold badges30 silver badges40 bronze badges

1

python -m compileall -q .

Will compile everything under current directory recursively, and print only errors.

$ python -m compileall --help
usage: compileall.py [-h] [-l] [-r RECURSION] [-f] [-q] [-b] [-d DESTDIR] [-x REGEXP] [-i FILE] [-j WORKERS] [--invalidation-mode {checked-hash,timestamp,unchecked-hash}] [FILE|DIR [FILE|DIR ...]]

Utilities to support installing Python libraries.

positional arguments:
  FILE|DIR              zero or more file and directory names to compile; if no arguments given, defaults to the equivalent of -l sys.path

optional arguments:
  -h, --help            show this help message and exit
  -l                    don't recurse into subdirectories
  -r RECURSION          control the maximum recursion level. if `-l` and `-r` options are specified, then `-r` takes precedence.
  -f                    force rebuild even if timestamps are up to date
  -q                    output only error messages; -qq will suppress the error messages as well.
  -b                    use legacy (pre-PEP3147) compiled file locations
  -d DESTDIR            directory to prepend to file paths for use in compile-time tracebacks and in runtime tracebacks in cases where the source file is unavailable
  -x REGEXP             skip files matching the regular expression; the regexp is searched for in the full path of each file considered for compilation
  -i FILE               add all the files and directories listed in FILE to the list considered for compilation; if "-", names are read from stdin
  -j WORKERS, --workers WORKERS
                        Run compileall concurrently
  --invalidation-mode {checked-hash,timestamp,unchecked-hash}
                        set .pyc invalidation mode; defaults to "checked-hash" if the SOURCE_DATE_EPOCH environment variable is set, and "timestamp" otherwise.

Exit value is 1 when syntax errors have been found.

Thanks C2H5OH.

answered Apr 19, 2021 at 8:25

user1338062's user avatar

user1338062user1338062

11.4k3 gold badges71 silver badges63 bronze badges

Perhaps useful online checker PEP8 : http://pep8online.com/

answered Sep 10, 2015 at 9:22

shakhmatov's user avatar

shakhmatovshakhmatov

2,8531 gold badge13 silver badges12 bronze badges

0

Thanks to the above answers @Rosh Oxymoron. I improved the script to scan all files in a dir that are python files. So for us lazy folks just give it the directory and it will scan all the files in that directory that are python. you can specify any file ext. you like.

import sys
import glob, os

os.chdir(sys.argv[1])
for file in glob.glob("*.py"):
    source = open(file, 'r').read() + 'n'
    compile(source, file, 'exec')

Save this as checker.py and run python checker.py ~/YOURDirectoryTOCHECK

answered Sep 10, 2020 at 20:19

Josh's user avatar

JoshJosh

86010 silver badges16 bronze badges

for some reason ( I am a py newbie … ) the -m call did not work …

so here is a bash wrapper func …

# ---------------------------------------------------------
# check the python synax for all the *.py files under the
# <<product_version_dir/sfw/python
# ---------------------------------------------------------
doCheckPythonSyntax(){

    doLog "DEBUG START doCheckPythonSyntax"

    test -z "$sleep_interval" || sleep "$sleep_interval"
    cd $product_version_dir/sfw/python
    # python3 -m compileall "$product_version_dir/sfw/python"

    # foreach *.py file ...
    while read -r f ; do 

        py_name_ext=$(basename $f)
        py_name=${py_name_ext%.*}

        doLog "python3 -c "import $py_name""
        # doLog "python3 -m py_compile $f"

        python3 -c "import $py_name"
        # python3 -m py_compile "$f"
        test $! -ne 0 && sleep 5

    done < <(find "$product_version_dir/sfw/python" -type f -name "*.py")

    doLog "DEBUG STOP  doCheckPythonSyntax"
}
# eof func doCheckPythonSyntax

answered Dec 27, 2016 at 11:04

Yordan Georgiev's user avatar

Yordan GeorgievYordan Georgiev

4,8281 gold badge51 silver badges53 bronze badges

Вы только что закончили сборку своего первого приложения командной строки Python. Или, может быть, ваш второй или третий. Вы изучали Python некоторое время, и теперь вы готовы построить something, больше и сложнее , но все еще работает в командной строке. Или вы привыкли к building and test веб-приложениям или настольным приложениям с графическим интерфейсом, но сейчас начинаете создавать приложения CLI.

Во всех этих и других ситуациях вам необходимо изучить и освоить различные методы тестирования приложения Python CLI.

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

*В этом руководстве вы узнаете четыре практических метода тестирования приложений командной строки Python:*
  • Отладка «Lo-Fi» с помощью + print () +

  • Использование визуального отладчика Python

  • Юнит тестирование с помощью pytest и mocks

  • Интеграционное тестирование

    *Бесплатный бонус:* ссылка: # [Нажмите здесь, чтобы получить наш шпаргалку по тестированию Python], в которой кратко описаны методы, продемонстрированные в этом руководстве.

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

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

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

_
Примечание : для простоты этот код не включает некоторые базовые рекомендации, такие как проверка наличия ключей в словаре.
_

В качестве первого шага давайте подумаем о наших объектах на каждом этапе этого приложения. Мы начнем со структуры, которая описывает Джона В. Общественность:

JOHN_DATA = {
    'name': 'John Q. Public',
    'street': '123 Main St.',
    'city': 'Anytown',
    'state': 'FL',
    'zip': 99999,
    'relationships': {
        'siblings': ['Michael R. Public', 'Suzy Q. Public'],
        'parents': ['John Q. Public Sr.', 'Mary S. Public'],
    }
}

Затем мы выравниваем другие словари, ожидая этого после вызова нашей первой функции преобразования + initial_transform +:

JOHN_DATA = {
    'name': 'John Q. Public',
    'street': '123 Main St.',
    'city': 'Anytown',
    'state': 'FL',
    'zip': 99999,
    'siblings': ['Michael R. Public', 'Suzy Q. Public'],
    'parents': ['John Q. Public Sr.', 'Mary S. Public'],
}

Затем мы собираем всю адресную информацию в одну адресную запись с помощью функции + final_transform +:

JOHN_DATA = {
    'name': 'John Q. Public',
    'address': '123 Main St. nAnytown, FL 99999'
    'siblings': ['Michael R. Public', 'Suzy Q. Public'],
    'parents': ['John Q. Public Sr.', 'Mary S. Public'],
}

И вызов + print_person + запишет это в консоль:

Hello, my name is John Q. Public, my siblings are Michael R. Public
and Suzy Q. Public, my parents are John Q. Public Sr. and Mary S. Public,
and my mailing address is:
123 Main St.
Anytown, FL 99999

testapp.py:

def initial_transform(data):
    """
    Flatten nested dicts
    """
    for item in list(data):
        if type(item) is dict:
            for key in item:
                data[key] = item[key]

    return data


def final_transform(transformed_data):
    """
    Transform address structures into a single structure
    """
    transformed_data['address'] = str.format(
        "{0}n{1}, {2} {3}", transformed_data['street'],
        transformed_data['state'], transformed_data['city'],
        transformed_data['zip'])

    return transformed_data


def print_person(person_data):
    parents = "and".join(person_data['parents'])
    siblings = "and".join(person_data['siblings'])
    person_string = str.format(
        "Hello, my name is {0}, my siblings are {1}, "
        "my parents are {2}, and my mailing"
        "address is: n{3}", person_data['name'],
        parents, siblings, person_data['address'])
    print(person_string)


john_data = {
    'name': 'John Q. Public',
    'street': '123 Main St.',
    'city': 'Anytown',
    'state': 'FL',
    'zip': 99999,
    'relationships': {
        'siblings': ['Michael R. Public', 'Suzy Q. Public'],
        'parents': ['John Q. Public Sr.', 'Mary S. Public'],
    }
}

suzy_data = {
    'name': 'Suzy Q. Public',
    'street': '456 Broadway',
    'apt': '333',
    'city': 'Miami',
    'state': 'FL',
    'zip': 33333,
    'relationships': {
        'siblings': ['John Q. Public', 'Michael R. Public',
                    'Thomas Z. Public'],
        'parents': ['John Q. Public Sr.', 'Mary S. Public'],
    }
}

inputs = [john_data, suzy_data]

for input_structure in inputs:
    initial_transformed = initial_transform(input_structure)
    final_transformed = final_transform(initial_transformed)
    print_person(final_transformed)

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

«Lo-Fi» отладка с печатью

Это один из самых простых способов тестирования. Все, что вам нужно сделать здесь, это + print + переменная или объект, который вас интересует — до вызова функции, после вызова функции или внутри функции.

Соответственно, они позволяют вам проверять ввод функции, вывод функции и логику функции.

Если вы сохраните приведенный выше код как + testapp.py + и попытаетесь запустить его с + python testapp.py +, вы увидите ошибку, подобную этой:

Traceback (most recent call last):
  File "testapp.py", line 60, in <module>
    print_person(final_transformed)
  File "testapp.py", line 23, in print_person
    parents = "and".join(person_data['parents'])
KeyError: 'parents'

В + person_data + отсутствует ключ, который передается в + print_person +. Первым шагом будет проверка ввода в + print_person + и выяснение того, почему наш ожидаемый вывод (печатное сообщение) не генерируется. Мы просто добавим вызов функции + print + перед вызовом + print_person +:

final_transformed = final_transform(initial_transformed)
print(final_transformed)
print_person(final_transformed)

Функция + print + делает здесь работу, показывая в своем выводе, что у нас нет ключа + parent + верхнего уровня — ни ключа + siblings + — но в интересах нашего здравого смысла, я буду покажу вам + pprint +, который печатает многоуровневые объекты в более читабельной форме. Чтобы использовать его, добавьте + из pprint import pprint + в начало вашего скрипта.

Вместо + print (final_transformed) +, мы вызываем + pprint (final_transformed) + для проверки нашего объекта:

{'address': '123 Main St.nFL, Anytown 99999',
 'city': 'Anytown',
 'name': 'John Q. Public',
 'relationships': {'parents': ['John Q. Public Sr.', 'Mary S. Public'],
                   'siblings': ['Michael R. Public', 'Suzy Q. Public']},
 'state': 'FL',
 'street': '123 Main St.',
 'zip': 99999}

Сравните это с ожидаемой окончательной формой выше.

Поскольку мы знаем, что + final_transform + не касается словаря + Relations +, пришло время посмотреть, что происходит в + initial_transform +. Обычно я бы использовал традиционный отладчик, чтобы пройти через это, но я хочу показать вам еще одно использование отладки печати.

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

Поскольку + initial_transform + — это, прежде всего, несколько циклов, и поскольку внутренние словари должны обрабатываться внутренним циклом for, мы должны проверить, что там происходит, если что-нибудь:

def initial_transform(data):
    """
    Flatten nested dicts
    """
    for item in list(data):
        if type(item) is dict:
            print "item is dict!"
            pprint(item)
            for key in item:
                data[key] = item[key]

    return data

Если мы встретим словарь внутри нашего ввода + data +, тогда мы будем предупреждены в консоли, а затем мы увидим, как выглядит элемент.

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

Однако в качестве упражнения я рекомендую поиск ошибок в этом коде, используя только отладку печати. Это хорошая практика, которая заставит вас подумать обо всех способах использования консоли, чтобы предупредить вас о различных событиях, происходящих в коде.

Заворачивать

*Когда использовать отладку печати:*
  • Простые объекты

  • Более короткие сценарии

  • На первый взгляд простые ошибки

  • Быстрые проверки

  • pprint — предварительно печатать печатные объекты

  • Быстрое тестирование

  • Легко использовать

  • В большинстве случаев вам нужно запустить всю программу, в противном случае:

  • Вам нужно добавить дополнительный код для ручного управления потоком

  • Вы можете случайно оставить тестовый код, когда закончите, особенно в сложном коде

Использование отладчика

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

Есть много отладчиков, и они часто приходят с IDE. В Python также есть a модуль с именем + pdb +, который можно использовать в REPL для код отладки. Вместо того, чтобы вдаваться в детали реализации всех доступных отладчиков, в этом разделе я покажу вам, как использовать отладчики с общими функциями, такими как установка breakpoints и watches.

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

Но давайте вернемся к контрольным точкам. Они будут добавлены там, где вы хотите начать или продолжить сеанс отладки. Поскольку мы отлаживаем метод + initial_transform +, мы захотим поместить его туда. Обозначим точку останова через + (*) +:

def initial_transform(data):
    """
    Flatten nested dicts
    """
(*) for item in list(data):
        if type(item) is dict:
            for key in item:
                data[key] = item[key]

    return data

Теперь, когда мы начнем отладку, выполнение будет приостановлено в этой строке, и вы сможете увидеть переменные и их типы в конкретный момент выполнения программы. У нас есть несколько вариантов навигации по нашему коду: step over, step in и step out являются наиболее распространенными.

Step over — это тот, который вы будете использовать чаще всего — он просто переходит к следующей строке кода.

Step in, пытается углубиться в код. Вы будете использовать это, когда столкнетесь с вызовом функции, который вы хотите исследовать более глубоко — вы попадете прямо к коду этой функции и сможете там проверить состояние. Вы также часто используете это, когда путаете это для step over. К счастью, step out может спасти нас, это возвращает нас к звонящему.

Мы также можем установить здесь watch, что-то вроде + type (item) is dict +, что вы можете сделать в большинстве IDE с помощью кнопки «add watch» во время сеанса отладки. Теперь это покажет + True + или + False + независимо от того, где вы находитесь в коде.

Установите часы и теперь перешагните так, чтобы вы остановились на строке + if type (item) dict: +. Теперь вы должны видеть состояние часов, новую переменную + item + и объект + data +.

Python Debugger Screenshot: Переменные наблюдения

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

def initial_transform(data):
    """
    Flatten nested dicts
    """
    for item in list(data):
        if type(data[item]) is dict:
            for key in data[item]:
                data[key] = item[key]

    return data

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

john_data = {
    'name': 'John Q. Public',
    'street': '123 Main St.',
    'city': 'Anytown',
    'state': 'FL',
    'zip': 99999,
    'relationships': {
        'siblings': ['Michael R. Public', 'Suzy Q. Public'],
        'parents': ['John Q. Public Sr.', 'Mary S. Public'],
    },
    'siblings',
    'parents',
}

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

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

Заворачивать

*Когда использовать отладчик Python:*
  • Более сложные проекты

  • Трудно обнаружить ошибки

  • Вам нужно осмотреть более одного объекта

  • У вас есть приблизительное представление о том, где происходит ошибка, но вам нужно сосредоточиться на ней

  • Условные точки останова

  • Оценка выражений при отладке

  • Контроль за ходом программы

  • С высоты птичьего полета состояние приложения

  • Не нужно точно знать, где происходит ошибка

  • Сложно вручную смотреть очень большие объекты

  • Длительный код займет очень много времени для отладки

Модульное тестирование с Pytest и Mocks

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

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

Введите юнит-тесты.

Модульное тестирование — это метод тестирования, который разбивает исходный код на распознаваемые блоки (обычно это методы или функции) и тестирует их по отдельности.

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

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

Повторяемость и изоляция являются ключевыми для такого рода тестов, хотя мы все еще продолжаем нашу тему сравнения ожидаемых результатов с фактическими результатами. Теперь, когда у вас есть общее представление о модульном тестировании, вы можете сделать небольшой обход и посмотреть, как проводить модульное тестирование приложений Flask с помощью minimum viable test suite .

Pytest

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

Общепринятым условием является размещение всех ваших тестов в каталоге + test + внутри вашего проекта. Поскольку это небольшой скрипт, достаточно файла + test_testapp.py + на том же уровне, что и + testapp.py +.

Мы напишем модульный тест для + initial_transform +, чтобы показать, как настроить набор ожидаемых входов и выходов и убедиться, что они совпадают. Основной шаблон, который я использую с + pytest +, — это настройка fixture, которая будет принимать некоторые параметры и использовать их для генерации входных данных теста и ожидаемых выводы, которые я хочу.

Сначала я покажу настройку фикстуры, и пока вы смотрите на код, подумайте о тестовых примерах, которые вам понадобятся, чтобы поразить все возможные ветви + initial_transform +:

import pytest
import testapp as app

@pytest.fixture(params=['nodict', 'dict'])
def generate_initial_transform_parameters(request):

Прежде чем генерировать исходные данные, давайте посмотрим, что здесь происходит, потому что это может запутать.

Сначала мы используем декоратор + @ pytest.fixture +, чтобы объявить следующее определение функции фиксатором. Мы также используем именованный параметр + params + для использования с + generate_initial_transform_parameters +.

Отличная особенность заключается в том, что всякий раз, когда используется декорированная функция, она будет использоваться с каждым параметром, поэтому простой вызов + generate_initial_transform_parameters + вызовет его дважды, один раз с + nodict + в качестве параметра и один раз с `+ dict + `.

Чтобы получить доступ к этим параметрам, мы добавляем специальный объект pytest + request + в сигнатуру нашей функции.

Теперь давайте создадим наши входы и ожидаемые результаты:

@pytest.fixture(params=['nodict', 'dict'])
def generate_initial_transform_parameters(request):
    test_input = {
        'name': 'John Q. Public',
        'street': '123 Main St.',
        'city': 'Anytown',
        'state': 'FL',
        'zip': 99999,
    }
    expected_output = {
        'name': 'John Q. Public',
        'street': '123 Main St.',
        'city': 'Anytown',
        'state': 'FL',
        'zip': 99999,
    }

    if request.param == 'dict':
        test_input['relastionships'] = {
            'siblings': ['Michael R. Public', 'Suzy Q. Public'],
            'parents': ['John Q. Public Sr.', 'Mary S. Public'],
        }
        expected_output['siblings'] = ['Michael R. Public', 'Suzy Q. Public']
        expected_output['parents'] = ['John Q. Public Sr.', 'Mary S. Public']

    return test_input, expected_output

Ничего удивительного в этом нет, мы настроили ввод и ожидаемый вывод, и если у нас есть параметр + 'dict' +, то мы изменим ввод и ожидаемый вывод, что позволит нам проверить блок + if +.

Затем мы пишем тест. В тесте мы должны передать прибор в тестовую функцию в качестве параметра, чтобы иметь к нему доступ:

def test_initial_transform(generate_initial_transform_parameters):
    test_input = generate_initial_transform_parameters[0]
    expected_output = generate_initial_transform_parameters[1]
    assert app.initial_transform(test_input) == expected_output

Тестовые функции должны начинаться с + test_ + и основываться на https://dbader.org/blog/python-assert-tutorial [+ assert + операторов]. Здесь мы утверждаем, что результат, который мы получаем от передачи нашего ввода в нашу реальную функцию, равен нашему ожидаемому результату. Когда вы запустите это либо в своей IDE с тестовой конфигурацией, либо с помощью + pytest + в CLI, вы получите …​ ошибки! Наш вывод еще не совсем правильный. Давайте исправим это, используя следующее упражнение — практический опыт неоценим, а применение того, что вы прочитали на практике, поможет вам вспомнить в будущем.

Mocks

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

Давайте добавим вызов внешней функции в + initial_transform +:

def initial_transform(data):
    """
    Flatten nested dicts
    """
    for item in list(data):
        if type(data[item]) is dict:
            for key in data[item]:
                data[key] = data[item][key]
            data.pop(item)

    outside_module.do_something()
    return data

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

@pytest.fixture(params=['nodict', 'dict'])
def generate_initial_transform_parameters(request, mocker):
    [...]
    mocker.patch.object(outside_module, 'do_something')
    mocker.do_something.return_value(1)
    [...]

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

Последний хитрый трюк — использовать + side_effect +. Помимо прочего, это позволяет вам смоделировать разные результаты при последовательных вызовах одной и той же функции:

def initial_transform(data):
    """
    Flatten nested dicts
    """
    for item in list(data):
        if type(data[item]) is dict:
            for key in data[item]:
                data[key] = data[item][key]
            data.pop(item)

    outside_module.do_something()
    outside_module.do_something()
    return data

Мы настроили наш макет следующим образом: список выходных данных (для каждого последующего вызова) передается в + side_effect +:

@pytest.fixture(params=['nodict', 'dict'])
def generate_initial_transform_parameters(request, mocker):
    [...]
    mocker.patch.object(outside_module, 'do_something')
    mocker.do_something.side_effect([1, 2])
    [...]

Заворачивать

*Когда использовать рамки модульного тестирования Python:*
  • Большие, сложные проекты

  • Проекты OSS

  • Pytest fixtures

  • deepdiff для сравнения сложных объектов

  • насмешник

  • Автоматизирует выполнение тестов

  • Может ловить много типов ошибок

  • Простая настройка и модификация для команд

  • Нудно писать

  • Должен быть обновлен с большинством изменений кода

  • Не копировать истинное приложение работает

Интеграционное тестирование

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

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

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

То, как вы это сделаете, сильно зависит от вашего приложения, например, наше тестовое приложение может запускаться самостоятельно с помощью + python testapp.py +. Однако давайте представим, что наш код представляет собой сегмент большого распределенного приложения, такого как конвейер ETL — в этом случае вам придется запускать всю систему на тестовых серверах с подкачанным кодом, запускать данные через него и убедиться, что он выполнен это через всю систему в правильной форме. За пределами мира приложений командной строки для интеграционного тестирования приложений Django можно использовать такие инструменты, как pyVows.

Заворачивать

*Когда использовать интеграционное тестирование в Python:*
  • Всегда 😉

  • Обычно после других методов испытаний, если они используются.

  • tox среда и управление автоматизацией тестирования

  • Посмотрите, как ваше приложение работает в реальных условиях

  • Большие приложения могут быть трудно точно отслеживать поток данных через

  • Должны иметь тестовые среды, которые очень близки к производственным средам

Собираем все вместе

В заключение — все тестирование CLI заключается в сравнении ожидаемых результатов с фактическими результатами с учетом некоторого набора входных данных. Методы, о которых я говорил выше, — это все способы сделать это, и во многих отношениях они дополняют друг друга. Это будут важные инструменты, которые вы поймете, когда продолжите создавать приложения для командной строки в Python, но это руководство является лишь отправной точкой.

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

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

  • Отладка печати — распечатка переменных и других маркеров в коде, чтобы увидеть, как выполняется выполнение

  • Отладчики — контролируют выполнение программы, чтобы получить представление о состоянии приложения и ходе выполнения программы с высоты птичьего полета

  • Модульное тестирование — разбивка приложения на индивидуально тестируемые модули и тестирование всех логических ветвей в этом модуле

  • Интеграционное тестирование — тестирование изменений кода в контексте более широкого приложения

А теперь иди и проверь! Работая с этими методами, обязательно дайте мне знать в комментариях, как вы их использовали и какие ваши любимые.

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

*Бесплатный бонус:* ссылка: # [Нажмите здесь, чтобы получить наш шпаргалку по тестированию Python], в которой кратко описаны методы, продемонстрированные в этом руководстве.

0 0 голоса
Рейтинг статьи
Подписаться
Уведомить о
guest

0 комментариев
Старые
Новые Популярные
Межтекстовые Отзывы
Посмотреть все комментарии

А вот еще интересные материалы:

  • Яшка сломя голову остановился исправьте ошибки
  • Ясность цели позволяет целеустремленно добиваться намеченного исправьте ошибки
  • Ясность цели позволяет целеустремленно добиваться намеченного где ошибка
  • Проверка office 2016 на ошибки
  • Проведенная оптимизация несомненно оказала пользу ошибка