Hi, I don't know anything about Codeception. Do you typically use assert* methods from PHPUnit in conjunction with Codeception methods, or do you use either PHPUnit or Codeception?

Anyway, we could register everything by default (there's no downside) and just mention in the README that this extension works well with Codeception out of the box. WDYT?

It was my wish from the beginning, but it not feasible.

Codeception ships with 2 different types of test, the Unit one which is a subclass of PHPUnit\Framework\TestCase and already works out of the box, and the Functional/Acceptance ones. In a nutshell, Functional/Acceptance tests gather multiple classes and their methods, copy-paste their signatures into a giant class, and proxy all the calls to the original ones. This allows the user to choose which module to use in the tests (i.e. Filesystem, Redis, Symfony, FTP...) and call all the available assertions/helper-methods under the $this hat. The Assertion module is one of them and is a proxy to the PHPUnit one.

What's the blocking? The giant class created lies under the project folder tree, and of course to be correctly autoloaded it must have the project's namespace, not a generic one.

I feel like this is related to #103

I don't exactly see the benefit to parametrize the assertion class instead of just fixing the FQCN. But I'm not familiar at all with codeception. Can you provide a link to that Acceptance class (or other relevant code) is it extending Assert?

I tried searching https://github.com/Codeception/phpunit-wrapper/tree/9.0/src but I didn't find it.

Can you provide a link to that Acceptance class (or other relevant code) is it extending Assert?

I doesn't exist, Codeception doesn't work this way.
It generates Traits that proxy the calls to PHPUnit's Assert class, and it generates them dynamically based on how the developer configured Codeception.

There is no way phpstan/phpstan-phpunit can fix #34 with an hardcoded code change.

The thing is making the class parametrizable will fix your use case by breaking PHP Unit analysis.

I think a better approach would be to create another package dedicated to codeception, dependant on this one. This way you can have two instance of the extension working at the same time.

The thing is making the class parametrizable will fix your use case by breaking PHP Unit analysis.

May I ask you how this break would happen?

I think a better approach would be to create another package dedicated to codeception, dependant on this one. This way you can have two instance of the extension working at the same time.

This PR already enable to have both PHPUnit and Codeception working in the same time, where do you see this isn't the case?

🤦 You are right I didn't understand the PR correctly. I somehow thought you were just feeding the existing service with another default value. But you are in fact creating other instances with different parameters.

This should work fine. 👍