Hello,
I'm looking for suggestions on how to best setup VDR for unit testing.
I'm working on a Python library that provides access to VDR's channels, timers, etc. Currently, it supports SVDRP and file-based access. Other types of connections like RESTful might follow.
Setting up unit tests for file-based components is rather straightforward. It doesn't require a running VDR and I can use test files as required.
Unit tests for SVDRP based components seem to require a running VDR in different reproducable states (data, time, VDR version, ...). I'm not sure what would be the best way to achieve that. May be, I can use a virtual machine, ideally without any real DVB hardware?
Thanks, Malte
Am 2013-07-29 12:25, schrieb Malte Forkel:
I'm working on a Python library that provides access to VDR's channels, timers, etc. Currently, it supports SVDRP and file-based access. Other types of connections like RESTful might follow.
Are you aware that a restful plugin already exists?
https://github.com/yavdr/vdr-plugin-restfulapi
Using svdrp is not a good idea, because of conflicts with other plugins that might use it to the same time (epgsearch)
Gerald
Am 29.07.2013 16:23, schrieb Gerald Dachs:
Are you aware that a restful plugin already exists?
https://github.com/yavdr/vdr-plugin-restfulapi
Using svdrp is not a good idea, because of conflicts with other plugins that might use it to the same time (epgsearch)
I'm sorry if my description was misleading.
I'm not writing any plugins. I'm writing a Python library (and scripts on top of it) that wraps VDR and some plugins (e.g. EPGsearch). The library currently uses SVDRP and VDR's files to access VDR data. I'm aware of the RESTful plugin. Using it would be an additional way to access VDR that could be added later on.
In order to write unit tests for my library, I'm seeking a way to setup VDR in a well-defined state against which the tests can be run.
Malte
Am 30.07.2013 09:09, schrieb Malte Forkel:
Am 29.07.2013 16:23, schrieb Gerald Dachs:
Are you aware that a restful plugin already exists?
https://github.com/yavdr/vdr-plugin-restfulapi
Using svdrp is not a good idea, because of conflicts with other plugins that might use it to the same time (epgsearch)
I'm sorry if my description was misleading.
No, it was not misleading, I understood your intention. I wrote it only, because I am sure that you shouldn't user svdrp for your library. Instead you should use the restfulapi or the vdr2dbus-plugin.
Gerald
!DSPAM:51f76eda84101847219701!
Am 30.07.2013 09:44, schrieb Gerald Dachs:
No, it was not misleading, I understood your intention. I wrote it only, because I am sure that you shouldn't user svdrp for your library. Instead you should use the restfulapi or the vdr2dbus-plugin.
Ah, ok. Thanks for your suggestions.
I started with those two connection types for the following reasons: - They are available with every VDR installation, - they promised to provide the most complete and up-to-date access because they are included with VDR and the plugins, respectively, and - they are supported by the plugins I was most interested in (mostly EPGSearch).
Fortenately, I havn't experienced any conflicts when using SVDRP connections in the library. I understand that there can be only one active SVDRP connection at any time, potentially causing timeouts. But that restriction could be an advantage, too, because it might protect against at least some inconsistencies caused by two or more clients accessing VDR's data at the same time.
The library is designed to be extensible with other connection types, like those you mention. But unless my scripts run into problems (and they havn't so far), I'd rather add some unit tests to what I already have first and extend the set of connection types after that (actually, the stubs for restful and dbus have already been there for a while :-).
Malte
Hi,
Am 30.07.2013 18:37, schrieb Malte Forkel:
Am 30.07.2013 09:44, schrieb Gerald Dachs:
No, it was not misleading, I understood your intention. I wrote it only, because I am sure that you shouldn't user svdrp for your library. Instead you should use the restfulapi or the vdr2dbus-plugin.
Ah, ok. Thanks for your suggestions.
I started with those two connection types for the following reasons:
- They are available with every VDR installation,
- they promised to provide the most complete and up-to-date access
because they are included with VDR and the plugins, respectively, and
- they are supported by the plugins I was most interested in (mostly
EPGSearch).
Fortenately, I havn't experienced any conflicts when using SVDRP connections in the library. I understand that there can be only one active SVDRP connection at any time, potentially causing timeouts. But that restriction could be an advantage, too, because it might protect against at least some inconsistencies caused by two or more clients accessing VDR's data at the same time.
The library is designed to be extensible with other connection types, like those you mention. But unless my scripts run into problems (and they havn't so far), I'd rather add some unit tests to what I already have first and extend the set of connection types after that (actually, the stubs for restful and dbus have already been there for a while :-).
If you want to unit-test your library, wouldn't it be the right way to write an vdr-mockup which returns expected values for different scenarios so that the behaviour of your library is tested? A "real-life" vdr wouldn't be a good test case because you never know if you cover all cases.
BTW, my plugin is called dbus2vdr. :)
https://github.com/flensrocker/vdr-plugin-dbus2vdr
I maintain a lib with a GDBus/GIO binding (actually just a written-down wrapper for gdbus-codegen and a bunch of examples as documentation how to us it):
https://github.com/flensrocker/libdbus2vdr
Someone actually has started a Python binding for it:
https://github.com/seahawk1986/pydbus2vdr
and a binding for restfulapi:
https://github.com/seahawk1986/pyrestfulapi
Regards, Lars.
Malte
Am 30.07.2013 19:07, schrieb Lars Hanisch:
If you want to unit-test your library, wouldn't it be the right way to write an vdr-mockup which returns expected values for different scenarios so that the behaviour of your library is tested? A "real-life" vdr wouldn't be a good test case because you never know if you cover all cases.
I don't know. If I knew enough about how VDR and its plugins behave under all kinds of circumstances to write a mockup, I could probably write a pretty good library without too much testing :-).
You are right about the problems caused by using a "real-life" VDR for testing. This is how I test my library right now. But these tests are hard to reproduce and to run automatically. The larger the library gets, the more regressions I'm likely to introduce.
I tend to think it might be easier and more realistic to use a regular VDR installation and control its environment to create reproducable test conditions. I was hoping someone might have done something like that before or even had a set of patches to make VDR a little more adapt for this kind of use.
Malte
-
Gerald Dachs -
Lars Hanisch -
Malte Forkel