Re: Setting connection parameters in tests

On 14/04/2008, Jorgen Austvik - Sun Norway <[email protected]> wrote:
> James Henstridge wrote:
>
> > Hi Jorgen,
> >
> > I've made some changes to the test suite since 2.0.6 that make it
> > easier to run the entire test suite in one go.  It uses the
> > PSYCOPG2_TESTDB environment variable to pick which database to use for
> > the tests, defaulting to "psycopg2_test".
> >
>
>  The new tests and way to start them looks very good!
>
>
> > Is this enough for your uses, or do you need the other environment
> > variables?  If so, could you produce a patch against the current
> > Subversion sources?  You can make a checkout with:
> >
>
>  Patch attached.
>
>  [ja155679@khepri02:psycopg2] svn diff | diffstat
>   __init__.py              |    3 +++
>   extras_dictcursor.py     |    2 +-
>   test_connection.py       |    2 +-
>   test_dates.py            |    2 +-
>   test_psycopg2_dbapi20.py |    3 ++-
>   test_quote.py            |    2 +-
>   test_transaction.py      |    6 +++---
>   types_basic.py           |    2 +-
>   8 files changed, 13 insertions(+), 9 deletions(-)
>
>
> > There has been a fair amount of work since 2.0.6, so patches against
> > subversion head are more useful than those against the last tarball at
> > this point.
> >
>
>  Thanks for the great work!
>
>  Applied patch is tested with one error (which I don't think is related):

Thanks.  I'll review and apply your patch when I get some time.



>  [ja155679@khepri02:psycopg2] PSYCOPG2_TESTDB=postgres python runtests.py
> ..........................................................E...............
> ======================================================================
>  ERROR: test_unicode (tests.test_quote.QuotingTestCase)
> ----------------------------------------------------------------------
>  Traceback (most recent call last):
>   File "/home/ja155679/devel/psycopg2/tests/test_quote.py",
> line 67, in test_unicode
>     curs.execute("SELECT %s::text;", (data,))
>  DataError: character 0xe282ac of encoding "UTF8" has no equivalent in
> "LATIN1"

Hmm.  My guess is that your database cluster has been created with a
LATIN1, so fails on this test (my DB is configured with UTF-8).  You
can check this with the following SQL:

    SHOW server_encoding;

The test in question should probably reduce the codepoints it tests if
the server encoding is not unicode.

James.