Support for multiple codepools

[daveherbert]

I've hit a bit of an issue in defining a target codepool for specs. I'm trying to write some specs for a module in the community codepool, in a project which has local specs.
In order to describe a spec for my community module, I've added the following to phpspec.yml:

mage_locator:
 [...snip...]
  code_pool: 'community'

This works fine for creating the particular spec, however I can no longer run against existing specs in the local codepool. It doesn't seem there is currently support for working with multiple codepools.

The issue now is how best to approach multiple codepool support. I'm thinking to add support to allow multiple values to be passed in the yml file, and then use a command option (i.e. "--codepool") to specify the target when describing.

It seems that might render the need for the value defined in the yml file redundant, as we could just run against all 3 codepools, and use the command option when describing. I'm not sure I'm keen on that idea though.

Any thoughts? 😄

[shanethehat]

I'm wondering if the value in the yaml file should reflect the describe target, and when using the run command the resource manager should search all code pools for specs to run if no specific query is given.

[shanethehat]

Including @amacgregor as the author of the current implementation

[daveherbert]

I still favour being able to have an override for describing, but maybe the yaml value reflects the default describe target?

[shanethehat]

Some time ago there was an argument to the command that set a code pool, although I don't believe it worked. It would be nice to have that back now that Allan has done all the groundwork to support it.

[debo]

My advice on this, since we have the command to specify the code pool during describe, is to then have the locator to behave like Magento in terms of folder priority local -> community -> core.

[shanethehat]

I don't think we do have the command to specify during describe any more, although I think it should be reinstated to override the yaml configuration.

Would there be any benefit to having the run locators care about the code pool order? If a user calls run without specifying a path, I would expect the tool to run specs from any code pool it finds them. Or do you just mean that it should search in that order but still run all the specs it finds?

[alistairstead]

I like that solution Shane.
—
Sent from Mailbox

On Mon, Sep 15, 2014 at 1:18 PM, Shane Auckland notifications@github.com
wrote:

Including @amacgregor as the author of the current implementation

Reply to this email directly or view it on GitHub:
#82 (comment)

[debo]

@shanethehat either ways

[jamescowie]

I think we spoke about the optional command line argument but at the time we opted for yaml based configuration option. What I see as being a working solution could be:

phpspec.yml still contains the default code pool for running and describing objects ( Useful if only developing a single module or for a single code pool )

However the command line could have a new option for describing and running specs:

phpspec run --codepool=local/community
phpspec descibe:block magespec_test/blockfile --codepool=local/community

If the command line argument is set then it takes priority over configuration.

[alistairstead]

How about codepool in the yml being an array of pools?

Then have the flag to inform run and describe commands. If there is an array in the yml and the flag is not specified then an interactive prompt provides a selection:

Which code pool would you like to use?

1. community
2. core
3. local
4. all

You could add another config value to define 4 as the default for run?

[daveherbert]

@jamescowie That sounds pretty much how I envisaged it to work for the command line option.

Would we then treat the yml value as a default option for using describe for new classes, but run against all codepools? Alternatively I was thinking we could define an array of codepools to run against in the yml, perhaps with the first one being the default for describe?

[jamescowie]

I like @alistairstead approach so phpspec.yml could look like:

extensions: [MageTest\PhpSpec\MagentoExtension\Extension]
mage_locator:
  spec_prefix: 'spec'
  src_path: 'public/app/code'
  spec_path: 'spec/public/app/code'
  code_pool: ['community','local']
  default_run_code_pool: 'all'
  default_describe_code_pool: 'local'

This would allow us to define a default option via configuration as a fall back, When running PHPSpec to describe or run without a command line flag we would show the interactive prompt for where to run specs from or where to describe them. We would then still offer a CLI overwrite to bypass the prompt screen with validation to ensure that the config is correct. E.g. describe core without core being configured to run..

I think this is the complete solution but it might be worth exploring the CLI only option with yaml configuration being the default fallback as a first pass.

The most basic solution is to have 2 config files for different code pools and pass the config file when running PHPSpec via -c flag. Far from ideal :)

[shanethehat]

I'm not sure that any code pool needs to be set for running specs.

The standard behaviour of phpspec is that when the run command is not
provided with a target path it will search for all supported spec classes
in the specs directory. I think that if a project contains specs from
multiple code pools, the default behaviour of the run command should be to
run all of them.

Too only run the specs from a single code pool the use would pass a path to
the run command:

phpspec run spec/public/app/code/community

I also don't think we should make it possible to use the core code pool, as
that would suggest that changing core code is somehow okay. Community and
local should be the only legal values.

[debo]

@shanethehat I was thinking about the same. I think the code pool should go away from yaml configuration and in good phpspec style the tool should guide the user through the auto generation process. So when describing the the class we are speccing MageSpec should ask us if we want create the spec first and for which code pool afterwards or viceversa, whichever fits better. When we then run the specs, phpspec standard behaviour should be preserved and anything that is under spec should be run unless otherwise specified.

[shanethehat]

I'm not so fond of introducing another manual step into the description process. I think that for the majority of users, one code pool per project will be sufficient, and so being able to define that somewhere once makes a lot of sense to me. Maybe instead of defaulting to local like we do now, we could prompt the user if no value is set in the yaml file.