pytest 8.2.0 calls `@property`s during unittest collection about pytest HOT 11 OPEN

@bluetech I think this might be similar to #12425 but wasn't entirely sure if it is same case so reported it separately.

from pytest.

Bisected to 1a5e0eb:

• #12089

from pytest.

I'm not near a computer, the property issue is familiar (my first patch to pytest was fixing exactly that..), but the _ part sounds very strange, does it really not happen if you remove the _variable assignment?

from pytest.

Right, sorry. In our code when _variable is not assigned we get exception thrown right away in code so I got wrong impression of this. Updated bug title and description. Seems just @property is needed to reproduce it.

from pytest.

Right. So the situation is this:

• During collection, pytest needs to find fixtures (methods decorated with @pytest.fixture)
• To do this, it scans all of the attributes of the class
• Scanning an attribute of a class, when the attribute is a property, causes it to run

This has always been an issue with non-unittest test classes. In 8.2 it also started becoming an issue for unittest classes, because we've made the unittest code consistent with the non-unittest code. Unfortunately it also exposes unittest classes to this deficiency.

The reason unittest wasn't affected previously is that it used to work like this: do the collection on the class itself, not an instance, then bind it to an instance only later. When you access the property attribute on the class itself, the property doesn't trigger.

You might ask, if the old unittest was safer, why not switch non-unittest to that instead of the other way? The reason is that it's a much more impactful change, and brings some issues of its own. For example, to which instance should a class-scoped fixture method be bound?

In general I do think collecting on the class instead of an instance is probably better, but it will need some work and breaking changes to get there.

Another fix to the issue is check if the attribute is a property before accessing it and skip it if so. @RonnyPfannschmidt has a draft PR to do it (it's the oldest open PR). Downside of that is performance overhead, breaking change, and some technical issues.

from pytest.