Dev Testing

This is mostly for automated back-end testing. For automated testing of front-end or UI components, see Using Qunit for testing JS.

Configuring The Test Database

In early 2015 we made a separate set of config files for using with automated tests, so that they could run against a separate database and not pollute the server's primary database. These are the steps that need to be taken in order to configure a server for running the automated test suite.

First, you need to make sure the local test directory exists on your server. Then, if you haven't done so already, copy the default test config file to the local test directory.

cd $LJHOME
mkdir -p ext/local/t
cp t/config-test-private.pl ext/local/t/config-test-private.pl 

Once you have a local copy of config-test-private.pl in the right place, edit it to include the correct connection info and password for your testing database. If you are using a dreamhack, the database should be named test_dreamhack_<username> and the password is likely the same password that was assigned to the dreamhack_<username> database you normally use. Ping sophie if you get an error trying to use this test database - it may not have been automatically created.

If your database setup is not clustered (most dreamhacks aren't), you should delete the 'c01' and 'c02' entries from %DBINFO and only use 'master'. You can also safely delete the entry for 'theschwartz' if you haven't configured that. This is the simplest example of a working config-test-private.pl on my dreamhack:

{
  package DW::PRIVATE;
 
  %DBINFO = (
       master => {
           dbname => "test_dreamhack_kareila",
           user => "dh_kareila",
           pass => "xxxxxxxxxxxx",
       }
  );
}

I also needed to make a local copy (i.e. in ext/local) of t/config-test.pl in order to delete the 'c01' and 'c02' entries from %DBINFO in that file as well. You may also need to add cluster1 => 1 to the 'role' hashref for 'master' in config-test.pl. (Does it also need adding to config-test-private.pl?) Finally, change @CLUSTERS and $DEFAULT_CLUSTER in t/config-test.pl to be (1) and [1], respectively.

IMPORTANT: Once the config files are copied and edited properly, there is one final step that must be taken, which is to initialize the test database.

cd $LJHOME
t/bin/initialize-db

This script effectively runs update-db.pl and texttool.pl on the test database. You should do this as often as you update your regular server database, so that any schema changes are adopted in both places. If the script gives you errors, there is likely a problem with your config files that needs to be corrected before you can proceed.

Running The Tests

To run the entire suite of tests:

cd $LJHOME
prove -r t/

To prove a specific test:

cd $LJHOME
prove t/sometest.t

If everything is working as it should, you should see the text "ok" printed once per test file, to indicate that the tests in that file all passed. Sometimes you will see the text "skipped" followed by a short explanation of why that set of tests was skipped. If a test fails, you should get a large amount of information to assist in diagnosing the problem, and you can get even more information by using prove -v. Running the entire test suite should take less than five minutes.

(See also Test process for QA testing, though this is less relevant to most devs)

Writing new tests

In an ideal world, test-driven development means writing a test to replicate the bug, fixing the bug, then checking that the test passes. Look at the lists of tests in $LJHOME/t/ to find something similar if needed.