Test files are not correctly recognized in PyCharm

@Julien_HENRY : I am using Sonar Lint in PyCharm. I should be clear here though… the rule that it is checking against is a valid rule… in Python, PEP8 style guide says that function and method names should be defined in snake_case. We are choosing to deviate from this guideline and allow PascalCase in the method names for only these pytest unit test files (since we feel it increases traceability).

I have an exception defined in my sonar-project.properties to handle this exception, but Sonar Lint does not use the file, so at the moment, we just ignore that error in those files.

Example from my sonar-project.properties:

# Rule specific ignores
# Ignore function name does not match regex in unit test files.
sonar.issue.ignore.multicriteria=e1
sonar.issue.ignore.multicriteria.e1.ruleKey=python:S1542
sonar.issue.ignore.multicriteria.e1.resourceKey=**/unit_tests/test_*.py

I really, really wish that Sonar Qube and Sonar Lint would also support the # noqa comment that is pretty standard across pylint, flake8 and other static analysis tools. This allows me to ignore a specific violation on a specific line. For instance:

def test_MyCoolClass_init():  # noqa: S1542
    ...

In this case, I could tell it myself to ignore that rule on that line.

1 Like

@Josh_Schneider your message is so valuable, with so many points I would like to ask/reply then I decided to move it to a separate thread to not create too much noise on the original topic about sonar-project.properties.

  1. using connected mode to define exclusions on the server
    If you bind your project to SonarQube or SonarCloud, AND if you define the exclusions in the server instead of in sonar-project.properties, SonarLint will apply the same exclusions.

  2. SonarLint knowledge of what is a test file in your project
    It seems that in Pycharm, there is no concept of “test sources folders” like in IDEA. This is probably consistent with Python project structure, where you can easily mix production and test code.
    SonarLint analyze all files as production code, and this might be a problem because some rules are designed to work only on production code or test code.
    I created a ticket to see what we can do about that: https://jira.sonarsource.com/browse/SLI-538

  3. Support of noqa
    To me it looks like a valid feature request. Would you mind creating a separate thread so that people could vote for it?

2 Likes

@Julien_HENRY : Sure, I will write up the a feature request for point #3. I far prefer this solution, in that it gives me control in the code to set which rules we ignore at the individual rule level, without having to change server configuration.

I will look into your suggestion on point 1.

As for your point 2, such is the nature of Python. We’re kinda loosey-goosey and configurable. There are standards, but you have the freedom to deviate from them if you wish. For unit tests, yeah, each unit test library (unittest, pytest, nose, etc) seem to have their own rules and structure, so I am not sure if trying to account for all of them is a good idea. If I have the ability to # noqa out the specific violations, then I have the power.

Thanks for engaging with me on this! A dev I am working with and I really love the integration straight into the IDE, as it helps ensure a baseline of quality across our codebase. :slight_smile:

1 Like

Hi @Josh_Schneider, there is a workaround for the #NOQA topic, I just mentioned it in this thread: Add noqa support to SonarLint for Python (and consider it for other languages) - #4 by Marco_Comi