Grilo ships a GTK+ test user interface called grilo-test-ui that can be used to test new plugins. This simple playground application can be found in the ‘grilo’ core source code under tools/grilo-test-ui/. If you have Grilo installed on your system, you may have this application installed as well.

This application loads plugins from the default plugin installation directory in your system or, alternatively, by inspecting the GRL_PLUGIN_PATH environment variable, which can be set to contain a list of directories where Grilo should look for plugins.

Once the plugin library is visible to Grilo one only has to start the grilo-test-ui application and it will load it along with other Grilo plugins available in the system.

In case there is some problem with the initialization of the plugin it should be logged on the console. Remember that you can control the amount of logging done by Grilo through the GRL_DEBUG environment variable. You may want to set this variable to do full logging, in which case you should type this in your console:

$ export GRL_DEBUG="*:*"

If you want to focus only on logging the plugin loading process, configure Grilo to log full details from the plugin registry module alone by doing this instead:

$ export GRL_DEBUG="registry:*"

In case your plugin has been loaded successfully you should see something like this in the log:

(lt-grilo-test-ui:14457): Grilo-DEBUG: [registry] grl-registry.c:188: Plugin rank [plugin-id]' : 0
(lt-grilo-test-ui:14457): Grilo-DEBUG: [registry] grl-registry.c:476: New source available: [source-id]
(lt-grilo-test-ui:14457): Grilo-DEBUG: [registry] grl-registry.c:683: Loaded plugin '[plugin-id]' from '[plugin-file-absolute-path.so]'

If your plugin is a Media Source (not a Metadata Source) you should be able to see it in the user interface of grilo-test-ui like this:

• If the plugin implements Browse you should see the media source objects spawned by the plugin in the list shown in the main view. You can browse the plugin by double-clicking on any of its sources.
• If the plugin implements Search you should see the media source objects spawned by the plugin in the combo box next to the “Search” button. You can now search content by selecting the media source you want to test in the combo, inputting a search text in the text entry right next to it and clicking the Search button.
• If the plugin implements query you should see the media source objects spawned by the plugin in the combo box next to the “Query” button. You can now query content by selecting the media source you want to test in the combo, inputting the plugin-specific query string in the text entry right next to it and clicking the Query button.

If your plugin is a Metadata Source then you should test it by doing a Browse, Search or Query operation in some other Media Source available and then click on any of the media items showed as result. By doing this grilo-test-ui will execute a Metadata operation which would use any available metadata plugins to gather as much information as possible. Available metadata obtained for the selected item will be shown in the right pane for users to inspect.

Simulating Network Replies

For offline testing of plug-ins, particularly in automated tests, it is useful to simulate and return predefined network replies. Therefore, Grilo provides a few facilities for mocking network replies.

To enable mocking, set the environment variable GRL_NET_MOCKED. The value of this variable is interpreted as the path of the mock configuration file to use. This file is a simple .ini file, split into a “default” section and one section per URL to mock.

[default]
version = 1
ignored-parameters = field1[;field2[;...]] or "*"

[http://www.example.com]
data = content/of/response.txt
timeout = 500

An easy way to capture the responses is to run your application with the environment variable GRL_NET_CAPTURE_DIR. GrlNetWc will then write each response into a file following the pattern “url-timestamp”. If the directory does not exist yet then it will be created.

The Default Section

This section needs to be present in any mock reply configuration file.

• version needs to be “1”.
• ignored-parameters is a semicolon separated list of query parameter names that can be used to map URLs to sections without paying attention to query parameters listed here. By setting a value of “api_key” a request for http://www.example.com?q=test+query&api_key=dummy will be answered with the mock data for http://www.example.com?q=test+query. Setting “api_key;q” or “*” will result in mock answer for http://www.example.com.

The URL Sections

The section title is used to map URLs to response files.

• data is a path to a text file containing the raw response of the websserver. The path may be relative to this configuration file or an absolute path.
• timeout may be used to delay the response in seconds. The default is to not delay at all.

Skip the data field to provoke a “not found” error.