Refactor pointer parametrization

[salotz]

I would like to propose a potentially breaking change to the pointer parametrization, however I don't want to just make the PR in case you would need to keep the old behavior.

First, I think the simplest case should be easier to write (and reflect what the current docs have in them), e.g.:

@pytest.mark.pointer(func)
def test_func(): ...

Instead of:

@pytest.mark.pointer(target=func)
def test_func(): ...

Second, I think to keep things clearer it would be good to refactor the property pointer to either a different mark e.g. pytest.mark.pointer_property(Class, 'property); or to use explicit keyword arguments pytest.marker.pointer(class=Class, property_name='property').

This would then allow a single marker to point to multiple functions via multiple positional arguments (although I don't really see that being that important).

Let me know what you think.

[jaklimoff]

Hey, @salotz ,
Thank you for the involvement!

I like the idea! Can you implement it? I think pytest.mark.pointer_property is better. We also can use same approach as mock package, where we have an option to pass whole string path to the object we want to mock.

So smth like this:

@pytest.mark.pointer('module.func')
def test_func():
    pass

and if we want to specify in another way

@pytest.mark.pointer.object(Class, 'property')
def test_func():
    pass

What do you think?

[salotz]

I asked in order to see if I should contribute upstream or not, so I'm happy to do so. What I proposed is fairly simple as its just rearranging how the args are handled, as for the other ideas, I will take a look at the code and see if I understand how to do so. I would say that we probably don't want to support too many redundant ways of doing things. From what I was guessing, the special property case was done because there was some difficulty you encountered.

The main API choice I think would be between the string version and the explicit version. I kind of like the explicit one since I can just handle importing it in my test module which would also serve as a nice validation step that the module/function actually exists. Whereas if we go with the string version we'll have to handle the validation that its a real module in the plugin code and that sounds error-prone and difficult to write and debug.

In any case I would split adding new features and rearranging the args into two issues/PRs.

[jaklimoff]

Yeah. Actually agree regarding the explicit version, because it also will be easier to do refactoring and mass renaming.