You stop the virtual machine managed by Vagrant by calling vagrant halt. If you want to completely get rid of the machine, you call vagrant destroy, which can be really useful when preparing the local setup.

Automatic sharing of the code base between the guest and host machines relieves you from manually deploying the code base. Basically, your deploy action reduces to just running migrations from time to time.

You access your newborn local deploy target by issuing vagrant ssh at the root of the code base, after which you are free to do anything. With the MySQL configuration shown previously in this appendix, you can access the database from within the virtual machine by issuing the following command:

$ mysql -u root -pmysqlroot crmapp

Do remember that your code base is not in the home directory of the Vagrant user, at which you end right after the vagrant ssh call, but in the /vagrant one, so doing cd /vagrant can easily become your habit.

The most important setup is the test suite carefully constructed in Chapter 2, Making a Custom Application with Yii 2, and Chapter 3, Automatically Generating the CRUD Code.

As was stated back in Chapter 3, Automatically Generating the CRUD Code, running acceptance tests too many times (more than 10, actually) will overfill the grid views in the CRUD interfaces, which are configured to show only 20 items per page. After that, tests start to fail.

So, it's up to you to manually clean the database after acceptance tests as they have no means to clean up themselves. Inside the code bundle provided for this book there is a script called reset_database.sh, which helps you in this task. It contains just four lines of shell code as follows:

# Drop the production database
mysql -u root -pmysqlroot -e "drop database if exists crmapp; create database crmapp default character set utf8 default collate utf8_unicode_ci";

# Initialize the RBAC setup in empty database
./yii migrate --interactive=0 --migrationPath='@yii/rbac/migrations'

# Run all our own migrations
./yii migrate --interactive=0

# Make the SQL data dump for Codeception
mysqldump -u root -pmysqlroot crmapp > tests/_data/dump.sql

In effect, running this script will completely rebuild your database to clean its state. Do not use something like that on the application deployed in production! The second helper script that is provided with this book is selenium.sh. This script will launch the local instance of the Selenium server configured in such a way that you will be able to run acceptance tests right there in the Vagrant box. It's not as reliable as using an actual remote connection to separate a deploy target (because a connection is being made to the localhost, bypassing DNS and other things like proxies), but it's convenient, as you are able to use it immediately. Launch this helper script in a separate command line, and then run the acceptance tests in another one.

The third helper script is called minify_assets.sh, and it's just running the correct invocation of the ./yii asset command described in Chapter 8, Overall Behavior, in the section about minifying assets.

Overall, the code bundle provided with this book is configured in such a way that you will be able to launch Vagrant box and then immediately be able to launch the full test suite using the single command:

$ ./cept run

This cept script is a shorthand to call the Codeception executable inside the vendor directory.