There are two sets of tests which we run in CI. Local (AR-JDBC) test and Rails activerecord tests. The next two sections details how to run each and customize behavior.
After you have built arjdbc (run rake), then you can try testing it (if you do not build then adapter_java.jar is not put into the lib dir). If you change any of the .java files you will need to rebuild.
Most DB specific unit tests hide under the test/db directory, the files included in the test directory are mostly shared test modules and helpers.
Rake tasks are loaded from rakelib/02-test-rake, most adapters have a
corresponding test_[adapter] task e.g. rake test_sqlite3 that run against DB.
To check all available (test related) tasks simply rake -T | grep test.
If the adapter supports creating a database it will try to do so automatically
(most embed databases such as SQLite3) for some adapters (MySQL, PostgreSQL) we
do this auto-magically (see the rake db:create tasks), but otherwise you'll
need to setup a database dedicated for tests (using the standard tools that come
with your DB installation).
Connection parameters: database, host etc. can usually be changed from the shell
env for adapters where there might be no direct control over the DB
instance/configuration, e.g. for Oracle (by looking at test/db/oracle.rb)
one might adapt the test database configuration using :
export ORACLE_HOST=192.168.1.2
export ORACLE_USER=SAMPLE
export ORACLE_PASS=sample
export ORACLE_SID=MAIN
Tests are run by calling the rake task corresponding the database adapter being tested, e.g. for MySQL :
rake test_mysql TEST=test/db/mysql/rake_test.rb
Observe the TEST variable used to specify a single file to be used to resolve test cases, you pick tests by matching their names as well using TESTOPTS :
rake test_postgres TESTOPTS="--name=/integer/"
Since 1.3.0 we also support prepared statements, these are enabled by default (AR) but one can easily run tests with prepared statements disabled using env vars :
rake test_derby PREPARED_STATEMENTS=false
We also can run our adapters against Rails ActiveRecord tests. There are two ways you can do this:
-
Run against local clone (by setting RAILS environment variable). This is helpful when you are adding puts or hacking on activerecord code directly.
-
Run against bundler provided clone (by setting AR_VERSION environment variable). This is useful when you want to submit to travis and want all the adapters to run against your code.
Note: RAILS will trump AR_VERSION and setting neither will assume version as set in the gemspec.
Make sure you have rails cloned somewhere:
git clone git://github.com/rails/rails.git
Set up a fully qualified RAILS environment variable. For example, if you were in activerecord direction you can just do something like:
export RAILS=`pwd`/../rails
Now that is this set up we may have changed the gems we need so we have to run bundler:
bundle install
Before you run tests you need to be aware that each support branch we have is written to run with a single significant release of rails (50-stable will only work well with rails 5.0.x). So you need to make sure you local copy of rails is checked out to match whatever you are testing (e.g. git checkout v5.0.6). Now you can run rails tests:
jruby -S rake rails:test_sqlite3
jruby -S rake rails:test_postgres
jruby -S rake rails:test_mysql
AR_VERSION is a very flexible variable. You can:
- specify tag (export AR_VERSION=v5.0.6)
- specify version (export AR_VERSION=5.0.6)
- specify SHA hash (export AR_VERSION=875bb788f56311ac4628402667187f755c1a331c)
- specify branch (export AR_VERSION=verify-release)
- specify nothing to assume LOADPATH has loaded it (export AR_VERSION=false)
Now that is this set up we may have changed the gems we need so we have to run bundler:
bundle install
Once you have picked what you want to test you can run:
jruby -S rake rails:test_sqlite3
jruby -S rake rails:test_postgres
jruby -S rake rails:test_mysql
Happy Testing!