Sourcery is getting in the way

[Josverl]

Description

I would like sourcery not to be in my face in my code all the time.
given the example below :

1. this is a test - why are you promoting the generate a test for every test that has been written ?
2. the function has a docstring (although not a tripple-quoted one - why are you promoting to generate a docstring
3. the proposed generated tests really make little sense at all, and all fail - taking away even more time and effort.

I do not like the way Sourcery tries to shoulder-wrestle itself into the foreground , and take away focus and screen real-estate from my code - I like Co Pilots UX approach much better.

there seem to be some basic rules :

• do not generate tests for test functions
• do not propose to write something that already exists
• do not add code lenses to every class and every function, just because

Currently the only option to influence this is to completely shut down ALL sourcery code lenses

if there is a more granular option, that allows me to tune the above behavior's to be somewhat more polite - or adhering to my preferences , then that would be appreciated.

For now I find myself turning Sourcery off, while there are definitely good things that I do like that go with that.

[reka]

Hi @Josverl,

Thanks a lot for your feedback.
You've raised multiple interesting points. Let me answer them one by one. 🙂

Generate Tests for Tests

I agree: Testing tests doesn't make sense. 👍
We'll remove this code lens for Python test files in the next version, 1.11.0

Generate Docstrings when There's One

This is a bit more tricky. We've received some feedback from users that this is useful in several cases. Especially, if the existing docstring happens to be outdated or incorrect.

More Granular Option when to Show Code Lenses

That's intriguing.
We'd love to hear more on that. What kind of preferences do you want to configure for the code lenses?