Just tried running the dmedia tests against the latest desktopcouch (r240), and it breaks the nice dc test idioms that Chad helped me with.
First problem seems to be that desktopcouch.application.tests.TestKeyring is now needed, which isn't installed by default and can't be readily imported by a 3rd-party app. I've mentioned this before, but I really think the essentially test fixtures that will be needed by 3rd-party apps should be installed by default. This is a small amount of code and could be located in a module not normally imported.
The other problem I see is that TestKeyring is only in-memory and can't be used across processes, which will make it impossible to test the dmedia D-Bus service the way I currently do. Currently I create a temporary directory for the testing Context, then launch `dmedia-service` with subprocess.Popen, passing the temporary directory via the special dmedia-service --couchdir option. In the subprocess I create an equivalent Context like this:
def dc_context(couchdir):
"""
Create a desktopcouch Context for testing purposes.
"""
assert path.isdir(couchdir)
return Context(
path.join(couchdir, 'cache'),
path.join(couchdir, 'data'),
path.join(couchdir, 'config'),
)
Being able to pass around the testing context via a single temporary directory is very handy. A simple solution for the TestKeyring would be to back it with a sqlite file located in the temporary directory.
As proper desktopcouch testing requires some fairly extensive setup, I'd really like the idioms to be well documented and utilize a simple, stable API. And I'd like us to come up with something that will work for dmedia also, so that people can use the same familiar testing API (this would be for apps building upon dmedia, like Novacut, PiTiVi, Shotwell, etc).
What do people think? For reference, I'm testing this in dmedia trunk at r125.
It would be interesting to know in which way you are writing your tests. From the description you are giving it looks like your test are not "very unit test like". There is nothing wrong with have tests that test a path rather than an specific feature, but doing so does provide a number of issues.
I personally do not see any issues in creating a package such as dekstopcouch-devel that can be used by those developers that are using desktopcouch and want to reuse its tests API. But before we do anything, shall we talk about how you are writing your tests in #novacut?