Mock Testing of Grilo Plugins

[Mathias Hasselmann <mathias openismus com>]

Hi,

Like Jens might have told already we are working on some few Grilo
plugins. To ensure proper quality we also want to mock test this
plugins. 

The idea is to have a mock version of GrlNetWc which reads the request
and then creates a fixed response from local files. This responses also
would include erroneous behaviour like timeouts. Another common approach
would be the use of some proxy server, but proxy servers are complex
pieces of software by itself, that need configuration and usually have
their own bugs. Therefore using a proxy server doesn't really fit into
my idea of regression testing.

Now the big question is how to inject the mock instance of GrlNetWc.
I see the following approaches:

1) Add a webclient attribute to GrlMediaPlugin, and let plugins
interested in mock testing use grl_media_plugin_get_webclient() instead
of grl_net_wc_new() to get a web client. This would keep the GrlNetWc
code simple, but would require code changes to plugins interested in
mock testing. Also it'd be trivial to accidentally use grl_net_wc_new()
in new code.

2) Same thing, but use a configuration parameter that tells the web
client's GType.

3) Add the possibility to inject a custom, static request handler into
GrlNetWc. This request handler(s) would catch each request passed to
GrlNetWc and in the case of the mock handler deliver results from local
files. For unknown files they'd just trigger an assertion. This approach
would avoid changes to plugin code, but it would _slightly_ increase the
complexity of GrlNetWc.

4) Use LD_PRELOAD to inject a custom version of GrlNetWc. This approach
would require no modifications at all to library or plugin code, but it
would break in the case of strict kernel policies, at least SE/Linux can
disable LD_PRELOAD. It also risks to break when new API is added to
GrlNetWc without updating the LD_PRELOAD hack. Indisputable it'd be a
hack.

Ciao,
Mathias