Difference between revisions of "Dev Testing"
(Link to front-end testing.) |
|||
Line 1: | Line 1: | ||
This is mostly for automated back-end testing. For automated testing of front-end or UI components, see [[Using Qunit for testing JS]]. | This is mostly for automated back-end testing. For automated testing of front-end or UI components, see [[Using Qunit for testing JS]]. | ||
+ | |||
+ | __TOC__ | ||
+ | |||
+ | |||
+ | = 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 | cd $LJHOME | ||
− | prove -r t | + | 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 <code>test_dreamhack_<username></code> and the password is likely the same password that was assigned to the <code>dreamhack_<username></code> database you normally use. Ping <dwuser>sophie</dwuser> 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 <code>%DBINFO</code> 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: | ||
+ | |||
+ | <syntaxhighlight lang="perl"> | ||
+ | { | ||
+ | package DW::PRIVATE; | ||
+ | |||
+ | %DBINFO = ( | ||
+ | master => { | ||
+ | dbname => "test_dreamhack_kareila", | ||
+ | user => "dh_kareila", | ||
+ | pass => "xxxxxxxxxxxx", | ||
+ | } | ||
+ | ); | ||
+ | } | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | I also needed to make a local copy of t/config-test.pl in order to delete the 'c01' and 'c02' entries from<code> %DBINFO</code> in that file as well. Finally, I changed <code>@CLUSTERS</code> and <code>$DEFAULT_CLUSTER</code> to be <code>(1)</code> and <code>[1]</code>, respectively. | ||
+ | |||
+ | <em><strong>IMPORTANT:</strong></em> 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: | To prove a specific test: |
Revision as of 05:21, 3 June 2015
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 of t/config-test.pl in order to delete the 'c01' and 'c02' entries from %DBINFO
in that file as well. Finally, I changed @CLUSTERS
and $DEFAULT_CLUSTER
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
http://dw-dev.dreamwidth.org/20733.html describes more about the tests.
(See also Test process for QA testing, though this is less relevant to most devs)