Internals - Set up standardized environment for testing and development

[niden]

There is a need for a standardized environment to be used for testing and/or development

Requirements

• Easy to setup
• Offer all the necessary services for the framework
• Ability to run the testing suite locally

Implementation

• The use of docker and nanobox.io satisfies the above needs
• Installation for various platforms
• Containers offer the necessary services for the application
• Can compile Phalcon and run suite

Status

• Set up environment with the boxfile.yml
• Add all the necessary services and related extensions (Redis, Postgresql etc.)
• Rebuild the test suite to cover as many methods as possible (for now)
• Create Integration test suite
• Create Cli test suite
• Create Unit test suite

Working Branch

https://github.com/niden/cphalcon/tree/T13578-setup-phalcon-environment

Coding standard

• We are using the Cest format of Codeception.
• Each test file represents a method of a component.
• Tests are written for each method accordingly.
• Keep each test file as small as possible to improve readability
• Keep each test with as few assertions as possible and as few steps as possible. It makes it easier to read
• Docblocks on each test are required
• The name of each test is the namespace and method and then the purpose. For instance

Phalcon\Acl\Adapter\Memory :: allow() has a test of aclAdapterMemoryAllow.

• Each test must have a call to $I->wantToTest() describing what is being tested. This helps with reading the output and identifying where an error has happened. The message contains the namespace/component and the method (see also docblock). For instance

$I->wantToTest('Acl\Adapter\Memory - allow() - try to allow twice');

[niden]

@dschissler Agreed. The environment should allow you to use any Zephir version from the relevant repo and compile Phalcon as needed.

[niden]

@dschissler Valid points.

The issue is not to get more people to use nanobox. We don't own stock there or anything like that. It has been however used for over a year now and it has worked as advertised. There is no need to know docker or anything like that. All you do is run a command.

The goal of this issue is to create quickly an environment so that people can develop in Zephir for Phalcon and be able to run the test suite without having to install a bunch of prerequisites.

The reason we are leaning towards nanobox is that there are no complex scripts or anything like that to provision the environment.

Your approach takes into account the environment (ubuntu, fedora etc.) which nanobox does not. That could very well be something we might want to check a bit later.

For now, the goal is to create this environment and to do so a lot of the tests have to be rewritten and organized so this is the focus for now.

[danhunsaker]

@dschissler I'm a former Nanobox employee, so I expect my input will be ignored or at least glossed over, but the fact it uses Docker under the hood doesn't at all mean it requires knowledge thereof. I'm not sure which aspects of Nanobox you investigated, but the version of the product being used, here, is a single config file that sets up the entire dev environment, no knowledge of the build system itself required, nor the stack it runs within. Since Docker is readily available on any Linux OS, and can be installed on macOS and Windows, and Nanobox itself will happily install VirtualBox and configure its own Docker VM (the same way macOS and Windows are supported by Docker's so-called "Native" versions) if you like, it bypasses most or all of the OS-specific issues folks face. Maybe you saw some early documentation on the Dockerfile approach which still hasn't been released?

At any rate. This approach requires users to install Nanobox, then run the nanobox run command, to ensure a full working dev environment which won't interfere or otherwise directly interact with other environments on the host. Your approach, while solid and tested, seems to install dependencies directly onto the host, so it misses those advantages.

That said, alternative approaches could be used. Some have been considered internally, and at the moment Nanobox has won out. It might be helpful to increase the transparency around this decision, here?

I'm not technically part of the Phalcon team (I'm assigned to Zephir at the moment), but I'm more than willing to provide what insight I have, as desired.

[danhunsaker]

For my part, if you're willing to maintain those scripts, we can easily list the link to them in the README, for those who want an alternative approach.

[niden]

This has been addressed