Move some of the Numpy tests out of TestParamDocChecker

[DanielNoord]

• Add yourself to CONTRIBUTORS if you are a new contributor.
• Write a good description on what the PR does.

Type of Changes

	Type
✓	🔨 Refactoring

Description

This does not cover all numpy tests as there are some issues with those that check raise documentation (it seems as if tests are incorrectly passing currently).
Just to make the other PR easier to review, let's merge this first!

[coveralls]

Pull Request Test Coverage Report for Build 1555034207

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 93.696%

---

Totals
Change from base Build 1550052772:	0.0%
Covered Lines:	14164
Relevant Lines:	15117

---

💛 - Coveralls

[Pierre-Sassoulas]

🎉 100 lines less to maintain, again ! Great work !

[Pierre-Sassoulas]

I'm curious, do you create this commit at the very end by rebasing and taking the value you had after moving everything ?

[DanielNoord]

Taken from missing_param_doc_required_Google as they tend to have the same tests and thus similar ignores. I don't think there are any unnecessary ignores in here (and it doesn't really hurt if there are as long as they are not the messages we want to test)

[Pierre-Sassoulas]

Ho alright, thank you for explaining :)

[Pierre-Sassoulas]

👌

[DanielNoord]

@Pierre-Sassoulas I took another look at the remaining numpy tests. Those are actually incorrectly passing indeed.
Do you want me to do a fix PR and move PR or can I do the moving of the tests and fix in the same PR?

Basically, the numpy checker doesn't recognise property's correctly and recognises none of the raise documentation.

[Pierre-Sassoulas]

Nice job finding the problem in tests ! Moving then fixing would permit to have a better history by just squashing both, but if it takes too much time I'm okay with mixing too.

[DanielNoord]

Moving>fixing is (nearly) impossible as I can't let the tests pass without fixing or accepting false positives.

I'll have a look somewhere this week what the best effort/reward balance would be.

[Pierre-Sassoulas]

Ok, I see the problem now, let's do both at the same time then, there's no point in fixing then moving it's more work for only theoretical benefit.

[DanielNoord]

@Pierre-Sassoulas The issue is more troublesome than I thought:
https://github.com/PyCQA/pylint/blob/a51a5486ebff7543ae4fb6943fac2558947fa974/pylint/extensions/_check_docs_utils.py#L529-L536

This is a pretty naive approach at validating the docstrings. What happens for the remaining tests is that the property_returns_lines matches the Google style as it is similar to Numpy. Therefore this method returns True, even though the raises sections does not match the Google style.

https://github.com/PyCQA/pylint/blob/a51a5486ebff7543ae4fb6943fac2558947fa974/pylint/extensions/_check_docs_utils.py#L175-L184
Because of the order of this tuple we match with Google before Numpy and thus never actually see that the docstring we're testing is not Google, but `Numpy.

To fix this we need to change how we validate docstrings. Something that takes into account when we match multiple types and then fixes the conflict between them.