Check node location attributes in unittests

[DanielNoord]

• Add yourself to CONTRIBUTORS if you are a new contributor.
• Add a ChangeLog entry describing what your PR does.
• If it's a new feature, or an important bug fix, add a What's New entry in
  doc/whatsnew/<current release.rst>.
• Write a good description on what the PR does.

Type of Changes

	Type
✓	🐛 Bug fix
✓	✨ New feature
✓	🔨 Refactoring

Description

List of unittests which "can't" be moved and are updated to now include location attributes:

• TestMultiNamingStyle

[Pierre-Sassoulas]

This will be a nightmare to review...

To be fair this is probably a nightmare to write too. How about we move most of this to the functional tests ? It's more understandable for contributor and a lot easier to maintain for us. Because a functional test would be reviewable with vscode + pylint (modulo finding a way to use a dev version in vscode) by opening the file and looking at the column displayed, right ?

[DanielNoord]

This will be a nightmare to review...

To be fair this is probably a nightmare to write too. How about we move most of this to the functional tests ? It's more understandable for contributor and a lot easier to maintain for us. Because a functional test would be reviewable with vscode + pylint (modulo finding a way to use a dev version in vscode) by opening the file and looking at the column displayed, right ?

Not sure if converting to functional tests will take less time though.. I have never done it, did it take you much time last time?

[Pierre-Sassoulas]

did it take you much time last time?

Well it's relatively fast, you copy paste code and then add the expected message where required (# [missing-docstring]) or remove unwanted message. But it will take longer if the file does not exist yet I guess. Not making a mess and organizing the functional test properly will become important if we massively move unittest to functional though.

[DanielNoord]

I'll start working on it then. Keeping this PR open to track the progress on it so we know when the unittests are "testing" end_line.

[DanielNoord]

We're under 100 failed tests on 3.10 now 😄

[Pierre-Sassoulas]

Only 36 tests left 🎉 but it look like the functional tests needs updating and there would be less than that.

[DanielNoord]

Finally ready for review!

[Pierre-Sassoulas]

There's still a surprisingly big number of tests that can"t be moved to functional, but this became clearly more manageable, I'm glad we won't have to change the line/col manually for the migrated tests. Amazing work you did there !

[Pierre-Sassoulas]

👍

[DanielNoord]

Turns out this is actually because node is optional in pylint itself 😅
I guess we can add that to our mental todo list for 3.0

[Pierre-Sassoulas]

Yeap, that's probably some work too :)

[DanielNoord]

There's still a surprisingly big number of tests that can"t be moved to functional

For some of the remaining tests it was simply just better to keep them as is. Some used parameterization or imported additional data which would be difficult to replicate in functional tests.

[Pierre-Sassoulas]

Some used parameterization

I think unittest works really well with parametrization when applicable. How about adding a little doc about tests : Prefer functional tests, unless there are a lot of similar cases that can be parametrized, or if you're using additional data ?

[coveralls]

Pull Request Test Coverage Report for Build 1573560118

• 26 of 28 (92.86%) changed or added relevant lines in 3 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage decreased (-0.003%) to 93.652%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
pylint/testutils/checker_test_case.py	16	18	88.89%

Totals
Change from base Build 1573470747:	-0.003%
Covered Lines:	14206
Relevant Lines:	15169

---

💛 - Coveralls

[DanielNoord]

Some used parameterization

I think unittest works really well with parametrization when applicable. How about adding a little doc about tests : Prefer functional tests, unless there are a lot of similar cases that can be parametrized, or if you're using additional data ?

I don't think we should give people reasons to write more unittests, they will probably already do so since it is the most common way of testing.
There are so many difficulties with config parsing, loading of checkers etc that we should really prefer functional test unless truly impossible.