TestKeyring prevents 3rd party apps from using dc test idioms

Bug #694909 reported by Jason Gerard DeRose on 2010-12-28
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
desktopcouch
Undecided
Unassigned

Bug Description

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.

summary: - TestKeyring prevents 3rd party apps from using dc test idoms
+ TestKeyring prevents 3rd party apps from using dc test idioms
tags: added: novacut
Manuel de la Peña (mandel) wrote :

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?

Jason Gerard DeRose (jderose) wrote :

Thanks for stopping by #novacut, mandel! And extra thanks for offering to promptly code up a solution!

For reference, here is the base test class I'm using to do the desktopcouch setup. This is only a slight modification of what Chad setup for me:

class CouchCase(TestCase):
    """
    Base class for tests that need a desktopcouch testing Context.
    """

    def setUp(self):
        self.home = TempHome()
        self.couchdir = tempfile.mkdtemp(prefix='dc-test.')
        self.ctx = dc_context(self.couchdir)

    def tearDown(self):
        stop_couchdb(ctx=self.ctx)
        self.ctx = None
        shutil.rmtree(self.couchdir)
        self.couchdir = None
        self.home = None

The dc_context() function is the same from the above comment.

Manuel de la Peña (mandel) wrote :

I have just made a branch in which the TestKeyring is moved to the platform module. This has been done so that tests can be ran in different platforms and will allow application developers to use the TestKeyring doing an import from the platform module in the following way:

form desktopcouch.application.platform import TestKeyring

I believe this solves two different problems:
    1. Allow test to be ran in diff platforms.
    2. Allows 3rd party developers to import the TestKeyring if needed.

I believe this would solve your first issue, that is, having to use TestKeyring, the second one we talked about (having to share the keyring over different process) I believe is better fixed by writing a small in memory keyring that exposes it data over dbus (I'm working on it during my free time)

I hope it helps :)

Changed in desktopcouch:
assignee: nobody → Manuel de la Pena (mandel)
Changed in dmedia:
milestone: none → 0.4
Jason Gerard DeRose (jderose) wrote :

For what's it's worth, I've worked around this in upcoming dmedia 0.4... I went back to running test in normal desktopcouch instance, but using the "dmedia_test" database. A bit less elegant, but tests run faster now.

Changed in dmedia:
importance: Undecided → High
assignee: nobody → Jason Gerard DeRose (jderose)
status: New → Fix Committed
Changed in dmedia:
status: Fix Committed → Fix Released
Changed in desktopcouch:
assignee: Manuel de la Peña (mandel) → nobody
Changed in dmedia:
status: Fix Released → Invalid
status: Invalid → Fix Released
no longer affects: dmedia
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers