October: OC Unit testing

[chrisvidal]

Expected behavior

Being able to run unit testing after doing the oc system updates for an old oc installation

Actual behavior

the testing unit framework (folder /tests/ at the root) is not present after the updates and then no unit testing are possible

Reproduce steps

installing a one year old oc version taht was not containing the testing unit frameowkr and perform all the updates.

October build

build 396

[LukeTowers]

Both the internal updater and the installer provide the consumer version of October, that is, without developer features like the unit tests.

When installing and updating through composer or git, you get the full developer version, which includes those features. The reason for this is that consumers that utilize those methods to update / install don't need the extra aspects of the project like unit testing so it doesn't make sense to include them like that.

[chrisvidal]

Alright, thanks @LukeTowers
So what do I have to do please to bring along the developer features in my situation ?

[LukeTowers]

You could download the repository from github and then copy the tests directory and server.php file into your installation, but it might make more sense to just install october through composer if you want to be developing with it and getting updates to those aspects.

I usually start my projects by

• installing via composer

• ignoring the existing git repository of October itself, creating my own using the following .gitignore:

/bootstrap/compiled.php
/vendor
composer.phar
.DS_Store
.idea
.env
.env.*.php
.env.php
php_errors.log
nginx-error.log
nginx-access.log
nginx-ssl.access.log
nginx-ssl.error.log
php-errors.log
sftp-config.json
selenium.php

# for netbeans
nbproject

# Exclude the OctoberCMS module folders from being included, they're pulled in via composer
/modules/**

# Exclude the builder plugin
plugins/rainlab/builder

# Exclude the symlink public directory made from artisan october:mirror public
public/

• Change the October dependencies in composer.json to pull in the dev branch (most up to date, not guaranteed stable though - equivalent of setting enableEdgeUpdates for updating via composer):

"october/rain": "~1.0",
"october/system": "dev-develop",
"october/backend": "dev-develop",
"october/cms": "dev-develop",

• Running composer update to pull in the latest dev branch, and then ensuring to commit the composer.lock file that is generated.

• Running php artisan october:env to generate a .env file for environment configuration and make the necessary changes to the config files to support it. After that I make the required changes to .env and commit an .env.example file with dummy config data for other users of the repository to reference.

• Running php artisan october:up to prepare the database by running any pending migrations (which will initialize the database if not done so already).

• Enabling edge updates in config/cms.php to pull in the dev versions of marketplace plugins and disabling core updates in the same file to prevent updating through the web interface. Also enabling assetDeepHashing to make developing my theme's LESS / SCSS files easier (as it will auto-detect changes two levels deep and recompile those assets when it does when that setting is enabled)

• Initialize a theme for my project or install one from the marketplace, then change the value of activeTheme in the config/cms.php file to that theme's code for other users of the repository

• Running php artisan october:fresh to remove the demo plugin and theme that ship with October by default.

• Running php artisan plugin:install RainLab.Builder to install the RainLab.Builder plugin for plugin scaffolding needs.

• Running php artisan october:mirror public --relative to setup a white list approach to security instead of the blacklist that's used by default

Finally, once that's all done and committed to the git repository, I consider that project initialized and use the following scripts for deployments / new environment setups:

# Install dependencies from composer.lock
composer install;
# Enable maintenance mode
php artisan down;
# Run any pending migrations
php artisan october:up;
# Remove and regenerate the symlinked public directory for whitelist approach to clean out any references that may have been removed and add any new ones that may have been added
rm -rf public;
php artisan october:mirror public --relative;
# Disable maintenance mode
php artisan up;

Not sure how much of this process you'll want to use, but just thought I'd share my personal development setup when working on October projects.

[chrisvidal]

Woooaaa you are awesome @LukeTowers thank you

I guess I am trying to just update my current installation so I dont have to reinstall everything ( plugins and setting, etc...)
grabbing the /tests/ folder, the server.php and the composer.json, and run the composer update, should do the trick ?

[LukeTowers]

You could possibly get away with just copying over the composer.json file and then running composer update. That should pull in all the stuff that you might be missing

[chrisvidal]

ok, i did it then tried to run my tests and got this Exception

````cmd
1) SmartBuild\Asia\Tests\Models\LogTest::test_updating_project_value
BadMethodCallException: Method accessible does not exist.

vendor/laravel/framework/src/Illuminate/Support/Traits/Macroable.php:59
plugins/smartbuild/asia/vendor/illuminate/support/helpers.php:414
plugins/smartbuild/asia/vendor/illuminate/support/helpers.php:414
vendor/laravel/framework/src/Illuminate/Support/Arr.php:327
vendor/laravel/framework/src/Illuminate/Database/Query/Builder.php:1602
vendor/laravel/framework/src/Illuminate/Database/Migrations/DatabaseMigrationRepository.php:53
vendor/laravel/framework/src/Illuminate/Database/Migrations/Migrator.php:79
modules/system/Classes/UpdateManager.php:365
modules/system/Classes/UpdateManager.php:133
modules/system/Console/OctoberUp.php:42
vendor/laravel/framework/src/Illuminate/Container/Container.php:507
vendor/laravel/framework/src/Illuminate/Console/Command.php:150
vendor/symfony/console/Command/Command.php:261
vendor/laravel/framework/src/Illuminate/Console/Command.php:136
vendor/symfony/console/Application.php:843
vendor/symfony/console/Application.php:188
vendor/symfony/console/Application.php:119
vendor/laravel/framework/src/Illuminate/Console/Application.php:64
vendor/laravel/framework/src/Illuminate/Foundation/Console/Kernel.php:159
vendor/laravel/framework/src/Illuminate/Support/Facades/Facade.php:215
tests/PluginTestCase.php:100
tests/PluginTestCase.php:100
tests/PluginTestCase.php:65
plugins/smartbuild/asia/vendor/phpunit/phpunit/src/TextUI/Command.php:147
plugins/smartbuild/asia/vendor/phpunit/phpunit/src/TextUI/Command.php:99
```

[LukeTowers]

Looks like's something wrong with the SmartBuild.Asia plugin, which you'd have to talk to the plugin author about.

[chrisvidal]

I am the author of it :)

it my test case i have only this:

public function test_updating_project_value()
{
        $this->assertEquals(true, true);
}

[LukeTowers]

I'm not sure what the problem is with your test there.

Also, just putting this here for any future visitors, documented the process to convert a wizard installed OctoberCMS instance to a composer enabled OctoberCMS instance: https://github.com/octobercms/docs/commit/450903d0b172ad6c0dd3fbfa3a159f599749b5ac

[daftspunk]

Might be related to #2065

[LukeTowers]

@chrisvidal Are you still having issues with this?

[lunfel]

@LukeTowers Very interresting to see your deployment process. I far as I can tell, you deployment process only updates the core of the cms? What happens when you load custom plugins? Do you commit them as part of the repo? Or do they have their own repository?

I'm asking, because I have read alot on deployment process with OctoberCMS, but it still seems there is something I don't get about it. Maybe there is something wrong with my workflow.

How do you proceed to migrate your local dev to production?

Let's say I am finished working a on client's web site. I have set up some marketplace plugins (through project id) and some custom plugins both having data configured (Photo galleries with albums in it, calendar with upcoming events, etc). How would you deploy all of this? How would you carry all this data to your prod server? Or do you just develop the plugins localy and setup the data when live?

So many questions. I feel there is something wrong with my workflow and I am trying to figure it out.

[bennothommo]

Closing as it has been over a month since any activity on this occurred and we are trying to figure out what issues are still relevant. If this is still something that you would like to see through to fruition please respond and we can get the ball rolling.

[LukeTowers]

@lunfel

Bit late of a response but:

Custom plugins that are available as composer packages are pulled in via composer. Any others are committed to the repo.

If there's data that's required for prod that I can't / wouldn't make sense to use seeders for I just copy it over manually after deploying.