[Grok-dev] Re: testing, in general [slightly OT]

Philipp von Weitershausen philipp at weitershausen.de
Thu Jul 24 16:23:53 EDT 2008


Toni Mueller wrote:
> I'm still wrestling with my database problem, trying to create a
> product in egg form after the hints in the Zope3 wiki. The egg must
> be usable inside Zope, and outside Zope, too.
> 
> I'm using the z3c.testsetup machinery.

z3c.testsetup isn't the best tool for setting up tests with under 
various layers (functional, integration, etc.).

> An important part of the egg is creating some tables in an SQL
> database, and populating them. The relevant part of the program runs
> just fine when called from the command line, but fails miserably when
> called via 'bin/test', because in that case, no tables get created, and
> subsequently, everything else fails, too.
> 
> I've discovered that the only difference is that, when trying to run
> the test suite, the egg thinks it is running under Zope.

Please describe what you mean when you say an "egg thinks it is running 
under Zope".

> It doesn't
> think so when run from the command line, and it also isn't run under
> Zope with the test... only that it somehow ("magically") picks up
> zope.sqlalchemy, which is part of the virtualenv I use anyway. It
> somehow doesn't pick that up when run from the command line.

It depends on how you invoke this command line and what how the command 
you invoke works.

> My guess is that, failing to have a Zope transaction, nothing of the
> SQLAlchemy transaction machinery works, too. This problem is
> exacerbated by the fact that it's 'forbidden' to manually say
> "session.commit()" while under zope.sqlalchemy, and that
> "session.flush()" seems to do absolutely nothing, except for generating
> one more error message.
> 
> Any ideas about how to fix it, or a better place to ask, please?

Basically, what you want to do is set up an integration testing layer 
that loads the necessary ZCML and sets up your database. It should dump 
and re-create the database before and after each test, because tests may 
  easily modify the database (and you don't want to leak such changes to 
other tests).

It would be nice if megrok.rdb perhaps provided the building blocks for 
such layers.



More information about the Grok-dev mailing list