Update/add acceptance tests for "config warnings" stacklevel

[nicoddemus]

Follow up to: #4440 (comment)

[SaiHarshaK]

Hi, can i work on this issue? i'm a newbie so some help is appreciated.Could you please explain the issue in detail.

[blueyed]

@SaiHarshaK
It is about writing tests for the fix(es) in #4440.

[davidfyu]

I would like to try working on this issue. Is there any update as to whether any acceptance tests have already been written for the fix(es) in #4440 at this time? Thanks!

[mandarvaze]

@davidfyu @SaiHarshaK Either of you working on this ?

[phloose]

I am also interested in working on this, but i don't really get what the fixes in #4440 are ?! Does it mean the introduction of the stacklevel=somenumber in _issue_config_warning? I need some clarification and help for starting :)

Edit: While skimming through the code i found that that _issue_config_warning was renamed to _issue_warning_captured

[nicoddemus]

Hi @xibalba01,

Sorry for not answering this, I must have missed the notification about this issue.

The tests are supposed to produce the warnings adjusted by #4440, for example, creating a test case where a module which was supposed to be rewritten is already imported, so the Module already imported so cannot be rewritten warning is issued, and make sure it points to a reasonable location instead of deep inside pytest's internals.

Looking at #4440, most of those have been removed by now, there are only a few left.

[phloose]

@nicoddemus Thanks for the explanation! Are there already some acceptance tests available that i could have a look at to know in which direction this should go?

[phloose]

@nicoddemus @RonnyPfannschmidt @blueyed I am still trying to understand how this will work... A bit more details would be really nice :) In the end these specific warnings in mentioned in #4440 need to be triggered, right? But exactly this is where i am struggeling... How to trigger these warnings?

[blueyed]

@xibalba01
They are hopefully covered with tests already (you could check the coverage report on codecov for the master branch to verify this).
Then just put an assert 0, 1, assert 0, 2 etc in front of them (using different numbers for them), and run the whole test suite. Then you should see what tests are executing the code, and could harden them then.

[blueyed]

@xibalba01
Also take a look at #5929 maybe, which is only a single one.