Remove assertions that operate on class/object properties

[sebastianbergmann]

Object-Oriented Programming (OOP) is a programming paradigm based on the concept of "objects", which can contain data and code: data in the form of fields (often known as attributes or properties), and code, in the form of procedures (often known as methods).

— Wikipedia

PHPUnit currently refers to "fields" (see above) as "attributes". This is (or will become) confusing considering the introduction of attributes in PHP 8 and their support in PHPUnit.

PHPUnit will be changed to use the term "property" instead of "attribute" where "field" is meant.

The following methods of PHPUnit\Framework\Assert will be removed in PHPUnit 10:

• assertClassHasAttribute()
• assertClassNotHasAttribute()
• assertClassHasStaticAttribute()
• assertClassNotHasStaticAttribute()
• assertObjectHasAttribute()
• assertObjectNotHasAttribute()
• classHasAttribute()
• classHasStaticAttribute()
• objectHasAttribute()

The following classes will be removed in PHPUnit 10:

• PHPUnit\Framework\Constraint\ClassHasAttribute
• PHPUnit\Framework\Constraint\ClassHasStaticAttribute
• PHPUnit\Framework\Constraint\ObjectHasAttribute

At this time, no replacements are planned as these assertions are not wildly used (to the best of my knowledge) and, if at all, should only be used in edge case situations that I consider outside the scope of PHPUnit's standard distribution.

[mfn]

Checked a (private) code base of mine and found a few uses of assertObjectHasAttribute and assertObjectNotHasAttribute

The use-case is when having to work with stdClass (e.g. from JSON deserialization) and there's no notion of what the actual shape is.

[mfn]

… and indeed, replacing/removing them was a no-brainer 😄

[uuf6429]

Will there be an alternative replacement or are we supposed to use plain-old-php for this?

-        $this->assertObjectHasAttribute('c', $sut->a->b);
+        $this->assertIsObject($sut->a->b);
+        $this->assertTrue(property_exists($sut->a->b, 'c'));

[florianajir]

@uuf6429 fixed by #5220 #5231

[imreg]

Thank you mate, @sebastianbergmann , you made us extra nonsense work for fixing our test environment

[uuf6429]

Thank you mate, @sebastianbergmann , you made us extra nonsense work for fixing our test environment

That's a bit harsh... especially when considering that:

1. you wouldn't be required to do any changes unless your test environment is on the bleeding edge
2. if you used the affected methods before, it means that they made sense to you at the time
3. refactoring code should be a breeze in a decent IDE - PhpStorm, for example, has special handling for deprecations
4. be grateful that the authors took the time to mark parts as deprecated before actual removal - many other projects do no such thing (you'd be lucky if they follow SemVer)

[lcharette]

The use-case is when having to work with stdClass (e.g. from JSON deserialization) and there's no notion of what the actual shape is.

Same for XML

[armanist]

The attribute assertion was really handy thing.. and if the issue only with new PHP attribute features, couldn't it be to rename them, something like?

instead of this:

assertClassHasAttribute()
assertClassNotHasAttribute()

we will have something like this:

assertClassHasProperty()
assertClassNotHasProperty()

[uuf6429]

@armanist please check the following comment a few places up: #4601 (comment)

In short it has been implemented in PHPUnit 10.1, similar to your suggestion.

[joneiros]

Found an usage of assertObjectNotHasAttribute() in my code.
I realize it doesn't look as nice, but the solution working for my (relatively simple) use case seems to be

$this->assertFalse(property_exists($myObject, $nonExistentPropertyName));

Is there functional reasons NOT to use this replacement approach?

[uuf6429]

@joneiros There are some minor differences:

• It doesn't check that the object is indeed an object (and you might get a type error if it wasn't)
• If the assertion fails, you'll get a generic "value expected to be false, but it is true" message. This can be fixed by passing your own message as the 2nd parameter though.

Anyway, you can see all that by checking the phpunit implementation (the deprecated version or the new one, linked above).

(in short and in my opinion, I'd keep using the one provided by phpunit)

@sebastianbergmann may I suggest updating the description of the issue to say that there will be in fact a replacement, to avoid more "me too" comments?

[AnjaLiebermann]

@armanist please check the following comment a few places up: #4601 (comment)

In short it has been implemented in PHPUnit 10.1, similar to your suggestion.

That's fine and dandy, but currently I get the warning with the hint to replace it with a method, which doesn't exist yet.
I am using PHPUnit 9.6.8

[FlorientR]

Hi !
So if I use PHPUnit 9.6.8 on PHP 8.0, I will always have the warning message .... What solution for don't have warning message ?

[stronk7]

So if I use PHPUnit 9.6.8 on PHP 8.0, I will always have the warning message .... What solution for don't have warning message ?

Stay sticky to PHPUnit 9.6.0 (the warnings were introduced in 9.6.1, AFAIK). It's really unfortunate that the new alternatives (assertObjectHasProperty() ... have not been also backported to the 9.x series, grrr, coz that makes the warning 100% useless.

Ciao :-)

[swiffer]

@stronk7 - they have been backported in 9.6.11 ;)

https://github.com/sebastianbergmann/phpunit/blob/9.6.11/ChangeLog-9.6.md

[stronk7]

Yeah, @swiffer, I was following the other issue, awesome!

Problem for us is that we also faced a similar problem with other deprecation messages (for example, the removal in PHPUnit 10 of expect* methods, and the deprecation message in 9.6.x without replacement) that would hit us (and all our plugins legion) if we jump to 9.6.x suddenly.

Still analysing if to add PHPUnit Polyfills may be a possible solution or we'll stay sticky to 9.5.x for the life of our released (stable) branches.

Ciao :-)