12:46 < thekorn> jplacerda: wow, great. the main question is: do we wan to be 
the cool kids on the block, or is it enough for us to do it the old school way?
12:47 < thekorn> if we want to be on the cool side of life, and use the state 
of the art python way to handle such situations, we propable want to use the 
fixtures module
12:48 < thekorn> ...and testtools, as we want to support python 2.5 too
12:49 < thekorn> the good thing about fixtures is: it already has a Fixture 
which sets env vars temporary on board
12:49 < thekorn> also a fixture to create temp dirs
12:49 < thekorn> and to start external scripts/processes
12:49 < thekorn> which is basically all we need
12:50 < thekorn> so with some syntactic sugar, a test would simple look like:
12:50 < jplacerda> It's not part of the standard lib though, is it?
12:50 < thekorn> def bootest(self):
12:50 < thekorn> ...   with EngineFixture() as engine:
12:51 < thekorn> ...      self.assert(engine.do_something(), 1)
12:51 < thekorn> jplacerda: no, but I'm fine with adding these dependencies
12:51 < jplacerda> okay, that looks quite neat :)
12:55 < jplacerda> thekorn: I'm thinking that most of the stuff could actually 
be updated using Fixtures
12:57 < thekorn> one good thing about using testtools + fixtures is that we 
don't need our custom test runner anymore, we can just run the tests, and the 
'sandbox' (esp. the private session bus) are just there
12:57 < thekorn> so noone will ever run the tests directly and destroy his 
systems activity log
12:57 < thekorn> etc
12:58 < jplacerda> sounds awesome
12:59 < jplacerda> thekorn: you're essentially proposing a re-write of the test 
system (which I like, as nothing is handled in a standardized manner atm)
12:59 < thekorn> exactly
12:59 < thekorn> it's some work, but might be worth it
13:00 < thekorn> maybe we can even write a generic DBusSessionBus Fixture which 
can land upstream in the fixture package
13:00 < thekorn> so other people with similar dbus server/client setups can 
reuse it
13:01 < thekorn> which moves some complex code of of zeitgeist

You received this bug notification because you are a member of Zeitgeist
Framework Team, which is subscribed to Zeitgeist Framework.

  create a default test sandbox

Status in Zeitgeist Framework:

Bug description:
  21:43 < RainCT> jplacerda: So there's a problem with the test system. It's 
supposed to set ZEITGEIST_DATA_PATH to a temporary directory, but it's only 
doing so for doctests (of which we don't have any anymore)
  21:44 < jplacerda> I was just looking at engine-test and something similar to 
what I was doing happens there
  21:46 < RainCT> jplacerda: If you're friends with unittests, feel free to 
figure out how to fix that. I can only think of putting of wrapping it around 
everything (just like ZEITGEIST_DEFAULT_EXTENSIONS -- but then all 
                  tests get the same temp directory) or subclassing 
unittest.TestCase and having all tests use that; not happy with either option :(
  21:46 < RainCT> jplacerda: Yeah, engine-test is also affected. The problem is 
in run-all-tests.py.

  This clearly needs to be fixed :)

Mailing list: https://launchpad.net/~zeitgeist
Post to     : zeitgeist@lists.launchpad.net
Unsubscribe : https://launchpad.net/~zeitgeist
More help   : https://help.launchpad.net/ListHelp

Reply via email to