Database configuration tests: How necessary?

[jhsu802701]

When I run the command "bin/rails test test/lib", two of the DatabaseConfig tests fail:

DatabaseConfigTest#test_username_is_specified_properly [/home/winner/shared/octobox/test/lib/database_config_test.rb:40]

DatabaseConfigTest#test_password_is_specified_properly [/home/winner/shared/octobox/test/lib/database_config_test.rb:77]:

Should I have MySQL set up in my local environment? What's the procedure for this? I'm used to PostgreSQL.

The first of these tests (for MySQL) fails simply because my username (for PostgreSQL) is not "root". The second of these tests (also for MySQL) fails because my username (for PostgreSQL) is not "".

Are these tests necessary? Are any of them necessary? I've never seen a Rails app with tests of the database. I just assume that if the database is set up properly, all of the tests pass. If the database is not set up properly, all of the tests fail.

The only places in the app where I see DatabaseConfig in use are in config/database.yml and in the "DatabaseConfig.is_postgres?" section of app/models/notification.rb.

[andrew]

There's a few application level code paths that are different depending on if users are running octobox with mysql vs postgres, which is why we have both options and run them both on travis.

Saying that, we should definitely stub out the details of the local mysql/postgres setup when running the tests to avoid failures like that

[jhsu802701]

What's the procedure for setting up MySQL in this app? I use a build_fast.sh script in my ruby_on_racetracks branch within my fork to provide a one-step build process. My code for setting up PostgreSQL is:

DB_NAME='octobox_test'
DB_USERNAME='winner1'
DB_PASSWORD='long_way_stinks'
echo "OCTOBOX_DATABASE_NAME=${DB_NAME}" >> .env
echo "OCTOBOX_DATABASE_USERNAME=${DB_USERNAME}" >> .env
echo "OCTOBOX_DATABASE_PASSWORD=${DB_PASSWORD}" >> .env

psql_command="CREATE ROLE ${DB_USERNAME} WITH CREATEDB LOGIN PASSWORD '${DB_PASSWORD}';"
sudo -u postgres psql -c"$psql_command"
wait

psql_command="ALTER USER ${DB_USERNAME} WITH SUPERUSER;"
sudo -u postgres psql -c"$psql_command"
wait

psql_command="CREATE DATABASE ${DB_NAME} WITH OWNER=${DB_USERNAME};"
sudo -u postgres psql -c"$psql_command"
wait

[andrew]

I think you also need DATABASE=mysql2 in .env

[jhsu802701]

Adding "DATABASE=mysql2" in .env wasn't enough. There's at least one more critical step that I'm missing.

[jhsu802701]

In my personal ruby_on_racetracks branch (https://github.com/jhsu802701/octobox/tree/ruby_on_racetracks), I have a build_fast.sh script for AUTOMATICALLY setting up Octobox in my local environment. The idea is to run this script after running the "git clone" command to download it.

Until the lib tests were reinstated in the "bundle exec rake --trace rubocop db:migrate test:skip_visuals" command, all the tests passed when I ran the build_fast.sh command.

For all Rails projects I'm on, I insist on having this build_fast.sh command. If having my Ruby on Racetracks elements is not an option for the mainline code, I keep them in my ruby_on_racetracks branch.

[jhsu802701]

From scrutinizing what happens in the Travis CI environment, I now understand that I shouldn't have the OCTOBOX_DATABASE_NAME, OCTOBOX_DATABASE_USERNAME, and OCTOBOX_DATABASE_PASSWORD environment variables set in the .env file. (The .env.example file is a guide.) I also need to change my PostgreSQL setup so that my regular Linux username is also a PostgreSQL superuser. Yes, it's becoming increasingly clear that I misread things earlier on. Having those lib tests disabled masked this problem.

[jhsu802701]

OK, I've managed to get all the tests to pass, including those MySQL username and password tests that were giving me trouble. In the local environment, the OCTOBOX_DATABASE parameters should NOT be set. This means that the username and password specified in config/database.yml parameters are the default values specified in DatabaseConfig: 'root' for the MySQL username and '' for both passwords and the PostgreSQL username. Given the blank username and password specified for PostgreSQL, I just create a superuser in PostgreSQL with the same username as that of the underlying Linux system and configure the pg_hba.conf to allow the postgres user to connect without a password (trust).