[pytest-dev] fixtures and pylint W0621

[Floris Bruynooghe]

Hi,

On 4 December 2013 15:05, lahwran <lahwran at lahwran.net> wrote:
> perhaps pytest.fixture could return a special object that rejects all
> operations, rather than the decorated function object; such that `theobject
> == 5` would produce a big flashy error in theobject.__eq__ indicating you
> need to actually use the fixture for this to work, maybe even with an
> example. Repeat for all magic methods that make sense. this object would
> maybe have a _pytest_fixture attribute, or conform to whatever protocol
> already exists for detecting fixture objects, such that the only thing you
> could do with such an object is check if it's a fixture and get the original
> function object from somewhere inside it. Any other operation would result
> in a flashy error.

This seems like a quite nice idea to me.


> On Tue, Dec 3, 2013 at 11:26 PM, holger krekel <holger at merlinux.eu> wrote:
>> Well, ok.  Pending further input, i made pytest accept pytest.fixture
>> decorated pytest_funcarg__ prefixed functions, see
>>
>> https://bitbucket.org/hpk42/pytest/commits/aa1f0505a3156b9feca43cd67c5afc95622b9ac5

I don't really like this change.  IIRC this was considered when the
decorator was introduced and the reason it  was not allowed originally
is because the signature is different between the different ways of
defining fixtures.  That can be very confusing too.

My first reaction on this pylint issue was to see if this can not be
fixed wit a pylint plugin.  And I still think this would be nicer then
the other proposals of trying to figure out how to name fixtures
differently.  The way of declaring fixtures right now is very nice and
readable.  Especially if lahwran's suggestion is implemented as that
would make any mistakes obvious (and to an experience python developer
they already are obvious).


>> Then again, my general recommendation is to put fixture functions into
>> conftest.py files and you then get a clean "NameError" in a test module
>> for the above example.  The docs use the "everything contained in test
>> module"
>> method, though, to make it easier to present getting-started examples.
>> Maybe it makes sense to mention this recommended conftest/test module
>> split earlier on.

Personally I tend to recommend people to declare their fixtures as
close to the code using it.  So if a fixture is only used in one class
declare it in that class.  I find it easier to manage which fixtures
are needed and know about the relevant ones without having to search
around.  Also if you have all test modules in package, like py.test,
you quickly end up with colliding fixture names and a giant and hard
to manage collection of fixtures in conftest.py.


Regards,
Floris


-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org