Codeception: Idea: Split codeception core and it's modules

[vysinsky]

Hi,
I would like to use codeception for unit testing because of nice API. But I do not need extra things so I do not need all the codeship's dependecies and it takes long time to install eg. on Travis CI.

Wouldn't it be better to split codeception core and its modules to different composer packages? Everyone can than install only modules which he needs. Each package could have own dependencies.

[vojtech-dobes]

:+1:

[samdark]

Nice idea for major version.

[Ragazzo]

yes , was talking about same to @DavertMik long time ago )

[splinter89]

Why not keep everything needed bundled in single package?
It's the easiest way for users, no need to choose:)

Instead, my proposition is to remove package/codecept.phar from repo, and attach it to releases - this will cut the project size by 40%! YO! That's almost one half!

[DavertMik]

@vysinsky I had such idea before.

I think this could be implemented by creating a 3rd-party repo codeception-core with all dependencies (except PHPUnit and Symfony Components) removed. It will be mirrored from original repo, and synchornized with it on each tag.

If this sounds like a plan, I could easily implement it. I.e. it will be a complete clone of this repo, but with some changes to composer.json. Thus, we won't need to wait for major version to get this done.

Instead, my proposition is to remove package/codecept.phar from repo

@splinter89 shit, it should have been gone. I was not intended to commit it. Dough... Sure it should be stored only on site.

[jmverges]

:+1:

[Naktibalda]

I started extracting modules and, unless someone finds a fatal flaw, I will start moving them to Codeception org and publishing on Packagist soon.
Here are the modules I extracted so far:
https://github.com/Naktibalda/module-rest
https://github.com/Naktibalda/module-zendexpressive
https://github.com/Naktibalda/module-apc

Naming convention:
modules use prefix codeception/module-, as above,
shared dependencies of module will use a codeception/lib- prefix, e.g. codeception/lib-innerbrowser,
shared dev depencies use a codeception/util- prefix, unless someone has a better idea,
examples:
https://github.com/Codeception/util-robohelpers
https://github.com/Naktibalda/util-rest-app
https://github.com/Naktibalda/util-universalframework

extensions use codeception/ext- prefix, e.g. codeception/ext-runfailed, codeception/ext-recorder.

[DavertMik]

@Naktibalda I see problems here

Dependency Graph

let's say to fix a bug in PhpBrowser we need to update innerbrowser. This will require PR into 2 repositories. Also - when PhpBrowser is updated and released, we need to update and release REST module as well. So this really looks like a huge dependency graph.

The same goes for tests. When I make a patch to lib/innerbrowser I need to be sure that this won't break PhpBrowser and all frameworks. So lib-innerbrowser should contain tests for those.

If we could have phpbrowser/rest/frameworks in one repository that would simplify the maintanance of those modules and compatibility with each other. However, that makes a trickier release process. To release only one module on change we would need to make repo split and push this update to a module repository, then tag it.

Compatibility

Let's say I'm stuck at Codeception 3 but I want to use module from Codeception 4. For instance, I'm writing tests for Symfony 4 application and I can't upgrade to symfony components v5 but I want to use latest WebDriver. As WebDriver depends on php-webdriver only the upgrade should go smooth. I could use codeception/base:2.0 + codeception/module-webdriver.
The question is if we can make modules like PhpBrowser, REST, to be compatible with Codeception 3 and symfony components v4.

[Naktibalda]

Re: Dependency graph

I think that InnerBrowser should run the tests of all frameworks and phpbrowser in the same way codeception/codeception repo runs them now.
The tests of all frameworks are external and must be checked out by the build process anyway, 2 repo problem isn't new.

Re: Compatibility

I think that modules shouldn't be linked to specific version of core, unless the module API changes (so please change it quickly if you think that it is absolutely necessary).

Codeception 3 is the current active version, it is a pre-module version and there is no need to make modules compatible with it.
Codeception 4 will be the first modularized version and from that point the development of core and modules will diverge.
Version 5 of core will be released quite soon after to support Symfony 5 components.
We will probably need a major version bump for Symfony/Laravel/Lumen moduless too.
All the other modules should be compatible with core 4 and 5.
I'm not sure if it will be necessary to restrict version of core in symfony modules, most likely restriction on versions of symfony components should do the job.

[Naktibalda]

Status table:

Module | Repository | Travis | Packagist | Current version
--- | --- | --- | --- | ---
AMQP | module-amqp | | codeception/module-amqp |
Apc | module-apc | | codeception/module-apc |
Asserts | module-asserts | | codeception/module-asserts |
Cli | module-cli | | codeception/module-cli |
DataFactory | module-datafactory | | codeception/module-datafactory |
Db | module-db | | codeception/module-db |
Doctrine2 | module-doctrine2 | | codeception/module-doctrine2 |
FTP | module-ftp | | codeception/module-ftp |
Filesystem | module-filesystem | | codeception/module-filesystem |
Laravel5 | module-laravel5 | | codeception/module-laravel5 |
Lumen | module-lumen | | codeception/module-lumen |
Memcache | module-memcache | | codeception/module-memcache |
MongoDb | module-mongodb | | codeception/module-mongodb |
Phalcon | module-phalcon | | codeception/module-phalcon |
PhpBrowser | module-phpbrowser | | codeception/module-phpbrowser |
Queue | module-queue | | codeception/module-queue |
REST | module-rest | | codeception/module-rest |
Redis | module-redis | | codeception/module-redis |
SOAP | module-soap | | codeception/module-soap |
Sequence | module-sequence | | codeception/module-sequence |
Symfony | module-symfony | | codeception/module-symfony |
Yii2 | module-yii2 | | codeception/module-yii2 |
WebDriver | module-webdriver | | codeception/module-webdriver |
ZF2 | module-zf2 | | codeception/module-zf2 |
ZendExpressive | module-zendexpressive | | codeception/module-zendexpressive |

Codeception without modules is in 4.0 branch: https://github.com/Codeception/Codeception/tree/4.0

[Naktibalda]

I finished the modules,
the next steps are:

• cleanup 4.0 branch a bit,
• release the last version of 3.1,
• release 1.0.0 of all modules,
• release 4.0.0 of codeception/codeception,
• update website,
• think what modules should be included to phar file

[Naktibalda]

I will try to move static documentation files and documentation and phar file generation to website repo https://github.com/Codeception/codeception.github.com/

[Naktibalda]

I released codeception/codeception 3.1.2 and changed the default branch to 4.0
Then I released 1.0.0 of all modules.
@DavertMik will create a migration command and then 4.0.0 can be released.

[Naktibalda]

Codeception is modular and (I hope) there is no way back.
The only thing which is blocking 4.0.0 release is upgrade script https://github.com/Codeception/Codeception/pull/5750