Phpunit: Would there be interest in a AssertUuid() method?

[jeroenvdgulik]

It would basically forward to assertRegExp with the regex needed for a Uuid. It would be more of a convenience/explicit feature, but since more people are starting to use Guid's in their application, I can imagine this could be helpful/useful.

It's quite trivial to implement and I would be able to PR it, but before investing time I'd like to gauge if there is demand for this, or if people would find it not useful at all.

[sebastianbergmann]

No, I do not think that such an assertion should be added to PHPUnit.

[mitchellvanw]

I could've used this several times already. Personally think it's a great idea.

[esokullu]

Almost all nosql databases today use uuid as their main ID keeper. @sebastianbergmann I'd recommend you to reconsider your decision.

[fefas]

I agree with @sebastianbergmann that this kind of assertion should not be added to PHPUnit library.

If you need to test something coming out of database or of a random UUID generation third-library, it means that you are not making an unit test anymore :)

[jeroenvdgulik]

I'm not sure why the source of the data has any relevance.

[fefas]

@jeroenvdgulik the argument was taking into account the level of testing not the source of the data.

@esokullu Anyway, since the source of the data is on the table: in my humble opinion, values being generated in any third-part code (for example, database or libraries) should not be asserted among the application tests.

[jeroenvdgulik]

in my humble opinion, values being generated in any third-part code (for example, database or libraries) should not be asserted among the application tests.

Well that's why I asked why the source of data is relevant. From an outside-in point of view, you shouldn't care how the internals generate the UUID. All you care about is the behaviour that some output adheres to what we consider valid UUID. If you're making the assumption "this comes from a database", or "this is generated by an 3rd party library" you're testing the implementation, not the behaviour, which makes for brittle tests.