testing, in general [slightly OT]

[Toni Mueller-4]

Hi,

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.

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. 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.

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?


Kind regards,
--Toni++
_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev

[Philipp von Weitershausen]

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.

_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev

[Toni Mueller-4]

Hi,

On Thu, 24.07.2008 at 22:23:53 +0200, Philipp von Weitershausen <philipp@...> wrote:
> Toni Mueller wrote:
>> 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.).

ok... I was wrestling with the zope.testing package, but it seemed like
I had to register every testcase individually, instead of adding the
whole egg wholesale.

>> 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".

In the relevant module, I have this:

try:
    from zope.sqlalchemy import ZopeTransactionExtension
except:
    pass # running w/o Zope


And, further down, I have

    try:
        Session = scoped_session(sessionmaker(bind=db.engine,
                                              extension=ZopeTransactionExtension(),
                                              autoflush=False,
                                              transactional=True))
    except:
        Session = scoped_session(sessionmaker(bind=db.engine,
                                              autoflush=False,
                                              transactional=True))


When I wanted to know better what's going on, I also added debug
statements like

   print "I'm now running under Zope"

into this, and observed different output when running under the
test script, and when running outside of it.

I have a dummy Grok project that contains a stripped-down version
of this stuff, but using the Zope integration as shown above, which
works. I did this first as a proof-of-concept.

>> 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.

Erm... sure, must be. I'm running inside the same virtualenv in both
cases, and in one case I run ./bin/test from the top-level dir of the
egg, and in the other case, I go to the directory where the module
lives, and run 'python module.py'.

> Basically, what you want to do is set up an integration testing layer  
> that loads the necessary ZCML and sets up your database.

The correct database gets accessed in both cases, and I've already
verified that the 'engine' and 'meta' data are the same. I've done
this by writing a setup function and passing this to z3c.testsetup's
register_all_tests() function.

I still didn't figure out how to do this with ZCML, however.

> It should dump  
> and re-create the database before and after each test,

This I also already do with the setup function.

> because tests may  
>  easily modify the database (and you don't want to leak such changes to  
> other tests).

Yes and no. What I'm trying to test at this point, is correctly setting
up the database, and loading sample data, which I'll need to "play with"
in subsequent tests. But I'm currently stuck at setting up the database,
which does not work when the whole thing runs via './bin/test'.

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

That's a different question, but at this point, I'm quite unsure about
how to use megrok.rdb from outside a Zope app. Also... one of the points
that I'm a bit hesitant about, is that I want/need to make use of a
significant number of non-object-oriented features of the database
engine (PostgreSQL in my case), which I don't yet see how to express
with megrok.rdb, SA's declarative etc.


Kind regards,
--Toni++
_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev