Namespaced Tests

Has anyone experimented with namespacing tests in third-party packages? Like if I made a library and Jill includes it with `composer require mgatner/libfoo`, and I want to supply tests for the user to verify functionality, ensure stability, work with pipelines, etc... Do I provide a Tests folder they would need to copy into somewhere? Or can they run the namespaced tests right out of /vendor with CI4’s tests and PHPUnit?

Looking into this for a developer on the slack channel. Will share my findings once resolved.

There’s a Slack channel? Is that public?
(And thanks!)

It is in the composer.json file, for sure. I suspect other places, too ... might have to beef that up.
https://codeigniterchat.slack.com

“Don't have an account on this workspace yet?
Contact the workspace administrator for an invitation”

http://codeignitersignup.ciblox.com/

Resurrecting this thread as it still baffles me. Now that I am more experience with the framework and have developed some addins, I think I would like to consider testing in three scenarios:

1. Testing a project
   
2. Testing a module, standalone
   
3. Testing a module, integrated
   

To clarify a bit:

• a project is a site or utility built in CI4 that you would want to run tests against, for example an ecommerce website that goes through a series of tests before changes are published to a production version
  
• a module or addin is a package that can be included into a project that adds functionality or otherwise enhances the project, for example an authentication library that is installed via Composer to handle user logins
  

Scenario one seems to me that it is covered pretty well in the docs (https://codeigniter4.github.io/CodeIgnit...rview.html): you add test cases into /tests and use the existing phpunit.xml.dist (or write your own) to run these tests. Scenarios two and three I think are currently possible but not documented or immediately apparent to someone (like me) who is new to testing. With CI4 grown more modular as it develops I believe these could use some attention.

Scenario two most fits a developer working on a module. Some modules could use raw PHPUnit and have test ignorant of the framework, but in most cases the module will include framework features like models and routing that cannot be tested without including the framework itself. In this case we need some way of installing the framework (e.g. `composer require --dev codeigniter4/framework`) and then some unspecified means of loading and namespacing it properly without necessarily installing or configuring it.

Scenario three most fits a developer wanting to use a module, or test its compatibility with an existing project. In a development instance the dev would `composer require foo/bar` and then somehow be able to run pre-written tests from the Foo\Bar\Tests namespace.

Just to note, Myth:Auth has an example of some of what Scenario Two needs but since it is still in production I'm not sure @kilishan would consider this "the right way".