Codeception 3.0 Roadmap

[DavertMik]

Here starts a discussion of what we'd like to see in Codeception 3.0. Any proposals are welcome, they can probably be added to a list. Currently I see the main goals for next major release are simplification and decoupling. By simplification I mean:

• [ ] ability to use Codeception for acceptance tests only (single suite)

installation should provide an option to use one suite only and for one suite-setup there can probably be an option to merge acceptance.suite.yml config with main codeception config

• [ ] moving most of important modules to the separate repositories #1233

in this case installing codeception for laravel and webdriver will probably require this config:

{
   "require-dev": {
        "codeception/base": "^3.0.0",
        "codeception/laravel-module": "^3.0.0",
        "codeception/webdriver-module": "^3.0.0"
   }
}

codeption/codeception will still be a main repo for developement. Also codeception/codeception will still provide all-in-one-package. Modules will be split to own repositories. By doing so will allow us keep separate changelogs and release things faster, on per module bases.

• [ ] programmatic interface: allow developers to create their own runners for PHP script.

That also involves refactoring of some messy places.

• [ ] drop support for PHP < 7 #3972
• [ ] YAML test format (for non-PHP developers)
• [ ] Deprecation of Cept format.

By deprecation I mean keeping abilty to run it but no longer mention it in documentation, remove generators for it

...(more will come)...

[NavyCoat]

Yeah, I will lovely see version made only for acceptance testing! :D

[DavertMik]

@NavyCoat you don't need to wait for 3.0, it is already planned for Codeception 2.3 :)

[Faryshta]

ability to use Codeception for acceptance tests only (single suite)

I love codeception cest classes for unit testing and functional testing. How about dividing the suites in repos?

• codeception/acceptance-suite
• codeception/functional-suite
• codeception/api-suite
• codeception/unit-suite

the idea of decoupling the modules is awesome too, it would ease the instal process a lot.

drop support for PHP < 7

awesome. Specially if you can jump to php7.1 directly since php 7.0 will love active support at the end of this year.

zend and yii2 are taking this route too specially for the support for nullable type hints.

[ThomasLandauer]

I was just about to suggest "Deprecation of Cept" when I found this issue :-)
Reasons:

• Only minimal syntax advantage over Cept
• One more question for starters (which one should I use?) - which is (in fact) irrelevant
• Anybody seeking really human-readable language will go for Gherkin anyway.

So I would say: Don't mention it in the docs anymore, but still keep it runnable for a few versions. Then mark it as deprecated and offer a simple tool to convert Cept to Cest.

[ThomasLandauer]

What's the plan for "YAML test format"?

[DavertMik]

@ThomasLandauer

What's the plan for "YAML test format"?

I had idea of writing tests in non-PHP from, declarative style in YAML

feature: "web test"
tests:
  "hello world":
  - amOnPage: "/"
  - click: ["Login" , "#nav"]
  - see: ['Hello world' , ".sidebar"]

But I didn't find any proof that this format is worth enough to invest time in it

[ThomasLandauer]

But I didn't find any proof that this format is worth enough to invest time in it

I agree! :-)

Two reasons:

• There is Gherkin! Yaml will never be easier than Gherkin. Any anybody being capable of following any syntax rules, can switch to very PHP.

• Your example may look somewhat nice at first glance. But imagine 10 links and the click line, then 10 in the see line!

[etki]

Would love to see suite merging or something like that. Currently we have smoke tests written partly in PHPBrowser, partly in WebDriver - that's two suites with different modules, but we need WebDriver only to verify crucial parts, so it would be cool to run Smoke suite that would auto-explode into SmokeLightweight and SmokeE2E.

Also it would be great if modules would have more responsibility, e.g. on exporting their actions. I would love to have WebDriver/PHPBrowser/etc. switching implementation (yes, i know the amount of discussions behind that), but this is rather hard since i physically have to implement all proxy methods.

[davidjeddy]

Built in parallel execution would be cool. Even as far as running each suite in separate process / threads during execution. Following on that running multiple suites in parallel would be awesome.

I realize Robo and Docker exists, maybe use them under the hood. codecept run would start separate process for each applications suite defined in the the base most codeception.yml.

[szymach]

Hello, Have you guys planned on supporting PHP 7.0 as well, or only the newest version of the 7 branch? If it possible, I would advise not supporting 7.0, since you will not be able to use better typehints introduced in 7.1.

Cheers.

[Naktibalda]

Codeception 5.0 will be released soon: https://github.com/Codeception/Codeception/discussions/6064