Skip to content


Subversion checkout URL

You can clone with
Download ZIP
Tree: aa616d28eb
Fetching contributors…

Cannot retrieve contributors at this time

158 lines (116 sloc) 5.756 kB
The Developer's Guide to the MusicBrainz Server
We use standard Perl tools for unit testing. Tests are located in the t/
directory. The preferred way to run them is to use the `prove` program from
Test::Harness. For example, to run all tests use:
$ prove -l t/
If you're using Carton, you should instead run:
$ carton exec -Ilib -- prove t/
Or if you want to run only specific tests:
$ carton exec -Ilib -- prove t/entity_artist.t
$ carton exec -Ilib -- prove t/entity*.t
A few of the files in t/ aggregate all the tests in the t:: namespace.
For example if you want to run a controller test such as
t::MusicBrainz::Server::Controller::WS::2::LookupArtist you should use
t/controllers.t like this:
$ carton exec -Ilib -- prove t/controllers.t :: --tests WS::2::LookupArtist
For t::MusicBrainz::Server::Edit:: tests use t/edits.t, and for the
remaining tests you can usually run t/tests.t. You can specify multiple
tests as a comma-separated list:
$ carton exec -Ilib -- prove t/tests.t :: --tests Data::URL,Entity::URL
JavaScript and Selenium tests
The tests in t/ also include interface tests, these will be skipped
unless you have SeleniumRC running. Similarly we have a set of
javascript unittests (using QUnit), which we run using phantomjs,
these will be skipped if phantomjs isn't found.
Selenium tests
We're using Selenium to run interface tests, to run these tests you
can use a regular development server and the Selenium IDE. Log in
with a user account with permission to make edits before you start a
Ofcourse a normal development server will have a different data set
compared to the test environment. When debugging selenium tests it
may be useful to run the musicbrainz server in the test environment
instead, to do that run the following commands:
$ script/
$ MUSICBRAINZ_USE_TEST_DATABASE=1 carton exec script/ -- -r
To do headless testing with selenium, it may be useful to create a
separate "selenium" user. This way your personal browser settings /
plugins will not affect the tests, and the tests will run in a clean
environment. This user needs to have a browser configured to connect
through a proxy (localhost:4444). In theory the proxy configuration
is taken care of by selenium, but that doesn't seem to work on linux.
To install selenium:
$ mkdir --parents ~/opt/selenium
$ cd ~/opt/selenium
~/opt/selenium$ wget
To run it, first configure some proxy servers, then run the server:
~/opt/selenium$ export http_proxy=localhost:4444
~/opt/selenium$ xvfb-run java -jar selenium-server-standalone-2.0b2.jar -forcedBrowserModeRestOfLine '*custom /usr/bin/chromium-browser'
This will use chromium as the browser (and chromium will use the proxy
set in the environment).
If some test is working in Selenium IDE but failing on Selenium RC, I
recommend starting the server as follows, this way you can see what's
happening in the browser:
~/opt/selenium$ java -jar selenium-server-standalone-2.0b2.jar -singleWindow -browserSessionReuse -forcedBrowserModeRestOfLine '*custom /usr/bin/chromium-browser'
Currently we have a single QUnit test file to run javascript tests.
It can be tested inside the browser by visiting (or
http://localhost:3000/static/scripts/tests/all.html on your local
development checkout).
It is more fun to be able to run those tests on the commandline, this
can be done with phantomjs.
To install phantomjs:
$ sudo apt-get install libqt4-dev libqt4-webkit # on debian
$ sudo apt-get install libqtwebkit-dev # on ubuntu
$ sudo apt-get install xvfb
$ cd ~/opt
~/opt$ git clone git://
~/opt$ cd phantomjs
~/opt/phantomjs$ qmake
~/opt/phantomjs$ make
Now you should be able to use it to run QUnit tests. A testrunner is
available in root/static/scripts/tests:
$ xvfb-run ~/opt/phantomjs/bin/phantomjs root/static/scripts/tests/phantom-qunit.js http://localhost:3000/static/scripts/tests/all.html
* at:INT -- artist type by ID
* ac:INT -- artist credit by ID
* artist:INT -- artist by ID
* artist:UUID -- artist ID by MBID (you need to do another lookup by ID)
* blog:entries -- The lastest entries from
* cat:INT -- cover art type by ID
* c:INT -- country by ID
* g:INT -- gender by ID
* label:INT -- label by ID
* label:UUID -- label by MBID (you need to do another lookup by ID)
* lng:INT -- language by ID
* lt:INT -- label type by ID
* link:INT -- link by ID
* linktype:INT -- link type by ID
* linkattrtype:INT -- link attribute type by ID
* mf:INT -- medium format by ID
* rgt:INT -- release group type by ID
* rs:INT -- release status by ID
* rp:INT -- release packaging by ID
* scr:INT -- script by ID
* tag:INT -- tag by ID
* wikidoc:TEXT-INT -- wikidocs by page title and revision
* wikidoc-index -- wikidocs index page
* wizard_session:INT:INT:<MIXED> -- release editor (wizard)
sessions by catalyst session ID, RE (random) session ID, and other specifics
* wt:INT -- work type by ID
Debug information
If you have CATALYST_DEBUG set to true, in DBDefs, the built in server
(script/ will run in a development environment. This will
cause debug information to be generated on every page, and all HTML pages will
have debug panels available to view this information. To get to these panels,
simply click the "?" icon in the top right of each page.
Jump to Line
Something went wrong with that request. Please try again.