Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Some modules are not loaded from suite config in 2.2.2 #3292

Closed
Mitrichius opened this issue Jun 29, 2016 · 8 comments
Closed

Some modules are not loaded from suite config in 2.2.2 #3292

Mitrichius opened this issue Jun 29, 2016 · 8 comments
Labels

Comments

@Mitrichius
Copy link
Contributor

@Mitrichius Mitrichius commented Jun 29, 2016

There is modules section of my suite config:

modules:
    enabled:
        - \Helper\CustomAsserts
        - \Helper\Api
        - \Helper\Export
        - \Helper\Common
        - Asserts
        - PhpBrowser:
            url: 'http://export.lc'
        - REST:
           depends: PhpBrowser
           url: 'http://export.lc/'

When I run build command in 2.2.2, first two helpers aren't loaded:

\ExportTester includes modules: PhpBrowser, REST, \Helper\Export, \Helper\Common, Asserts
 -> RhApiTesterActions.php generated successfully. 0 methods added

Same config on 2.2.1:

\ExportTester includes modules: \Helper\CustomAsserts, \Helper\Api, \Helper\Export, \Helper\Common, Asserts, PhpBrowser, REST
 -> RhApiTesterActions.php generated successfully. 0 methods added

I've changed helpers' order with same result: first two are ignored.
As w/a: I moved Rest and PhpBrowser modules to the beginning, all helpers were loaded.

@nnnikolay
Copy link

@nnnikolay nnnikolay commented Jun 29, 2016

I can confirm the same behaviour

With following config file

enabled:
    - \Helper\Functional
    - REST:
        depends: PhpBrowser
        url: http://test.app/
    - Db

it does not work

With that version

enabled:
    - REST:
        depends: PhpBrowser
        url: http://test.app/
    - \Helper\Functional
    - Db

it works fine on 2.2.2

@DavertMik
Copy link
Member

@DavertMik DavertMik commented Jul 5, 2016

I couldn't reproduce it but I will try, this is my first priority to work on
If anyone can share project reproducing this issue - please do

@Mitrichius
Copy link
Contributor Author

@Mitrichius Mitrichius commented Jul 5, 2016

@DavertMik, looks like it's reproduced only when some modules are enabled in global config.
github-3292.zip

@glensc
Copy link
Contributor

@glensc glensc commented Jul 5, 2016

i can confirm similar problem when i have .dist and .dist.yml files present:

my acceptance.dist.yml:

class_name: AcceptanceTester
modules:
    enabled:
        - Filesystem
        - PhpBrowser:
            url: http://localhost/eventum/
        - \Helper\Acceptance

and acceptance.yml:

modules:
    enabled:
        - PhpBrowser:
            url: http://localhost/~glen/eventum-setup/

if i renamed "enabled" to "enabled2" in acceptance.yml problem disappeared,

looks like issue of merging two configs?

@DavertMik
Copy link
Member

@DavertMik DavertMik commented Jul 23, 2016

Thanks @Mitrichius I'm using your sample to reproduce it as well.

Looks like this bug is far more deeper and looks like appeared in 2.1. When arrays are merged from global and local configs values arrays are overridden and arrays are not merged.

DavertMik added a commit that referenced this issue Jul 23, 2016
DavertMik added a commit that referenced this issue Jul 23, 2016
@loesalleman
Copy link

@loesalleman loesalleman commented Jul 27, 2016

Hi, since updating to 2.2.3 I experience the following exception when running my tests locally:[Codeception\Exception\ModuleConflictException] Helper\PhantomWebDriver module conflicts with Helper\ExtendedWebDriver

PhantomWebDriver and ExtendedWebDriver are both custom extensions on the WebDriver module.

I work with config files acceptance.suite.yml and acceptance.suite.dist.yml (see below). The problem occurs when I run --env phantomjs. It looks like that, although running locally, codeception loads the default module from the dist.yml file concurrently with my local --env phantomjs specified module. Changing the enabled modules in the files confirmes this behaviour.
I do not expect this to be the desired behaviour and expect this to be a bug resulting from the mentioned fix, am I right @DavertMik ? Thanks in advance.

acceptance.suite.yml:

class_name: AcceptanceTester
modules:
    enabled:
        - \Helper\ExtendedWebDriver:
env:
    phantomjs:
        modules:
            enabled:
                - \Helper\PhantomWebDriver:

acceptance.suite.dist.yml:

class_name: AcceptanceTester
modules:
    enabled:
        - \Helper\ExtendedWebDriver:
env:
    phantomjs:
        modules:
            enabled:
                - \Helper\ExtendedWebDriver:
@DavertMik
Copy link
Member

@DavertMik DavertMik commented Jul 27, 2016

If those modules extend the same class they will conflict, this is expected behavior. They should not be used together. Probably they both instantiate browser session and this is not something you expect to.

Sorry I have little understanding on what your extended helpers do but I have several suggestions that might help you.

  1. override _conflicts method of PhantomWebDriver:
    public function _conflicts()
    {
        return 'Codeception\Lib\Interfaces\Web';
    }
// change to 
    public function _conflicts()
    {
        return null;
    }

this will disable conflict checks for this module.

2 Probably cleaner approach, make PhantomWebDriver not to extend WebDriver module but to connect to \Helper\ExtendedWebDriver as it is described in documentation

$this->getModule('\Helper\ExtendedWebDriver')->...
// you can get webdriver instance:
$this->getModule('\Helper\ExtendedWebDriver')->webDriver

3 You can also disable a module in environment, so if you use PhantomJS helepr you can inherit it from ExtendedWebDriver and enable only it in tests:

env:
    phantomjs:
        modules:
            disabled:
                - \Helper\ExtendedWebDriver
            enabled:
                - \Helper\PhantomWebDriver

Sorry for the mess with this issue but this was definitely a bug in merging configs. Now when conflicts are merged properly you receive conflicts error.

I hope it helped.

@loesalleman
Copy link

@loesalleman loesalleman commented Jul 28, 2016

Thanks @DavertMik . I now have a better understanding of how the modules are loaded and I am certainly able to resolve my issue with your suggestions. The easiest way was adding the disabled option, but I will also look into your second suggestion to make a cleaner use of the extension.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.