Test framework in memory database

[Mikeal Rogers]

I'm working on adding some selenium support in to the test framework.

The first thing i obviously had to do was get the test server up and running at the beginning of the tests. I completed this but ran in to one large issue.

The test framework defaults to using an in memory database if it sees that sqlite is set as the db type. For some reason the test environment created by the test framework with a sqlite in memory database fails when running the server. I've tested this by just running django.core.management.runserver() after the environment is setup and making a request -- the traceback is below. Of the 2 days I spent writing this, 1.5 were spent tracking this issue.

Seeing this issue made me question why using an in memory database is the default test environment if it differs enough to cause this problem. I removed the in memory default from the framework (although if you configure TEST_SERVER_NAME to ":memory:" it'll still work) and patched the db creation and removal code to account for sqllite in both cases. I've also written HttpTestCase, which inherits from unittest.TestCase and handles the startup and shutdown of the test server.

After finishing this I realized it's quite useful on it's own, even without the selenium bindings. I'm attaching the diff to this mail but I don't know if I should just add this patch as an attachment to my current task 2867 for Selenium support in the test framework or if I should create a new task for adding live http testing support to the test framework and then attach it to that task.

Thanks,

-Mikeal

[Malcolm Tredinnick]

Hey Mikael,

On Thu, 2006-10-05 at 20:16 -0700, Mikeal Rogers wrote:
> I'm working on adding some selenium support in to the test framework.
>
>
> The first thing i obviously had to do was get the test server up and
> running at the beginning of the tests. I completed this but ran in to
> one large issue.
>
>
> The test framework defaults to using an in memory database if it sees
> that sqlite is set as the db type. For some reason the test
> environment created by the test framework with a sqlite in memory
> database fails when running the server. I've tested this by just
> running django.core.management.runserver() after the environment is
> setup and making a request -- the traceback is below. Of the 2 days I
> spent writing this, 1.5 were spent tracking this issue.
>
>
> Seeing this issue made me question why using an in memory database is
> the default test environment if it differs enough to cause this
> problem. I removed the in memory default from the framework (although
> if you configure TEST_SERVER_NAME to ":memory:" it'll still work) and
> patched the db creation and removal code to account for sqllite in
> both cases. I've also written HttpTestCase, which inherits from
> unittest.TestCase and handles the startup and shutdown of the test
> server.

Excuse me for being very dense here, but I'm missing what's going on
here. You found a problem with in-memory SQLite and then did or didn't
solve it? Or you just worked around it?

Signed,
Confused.

[Mikeal Rogers]

> Excuse me for being very dense here, but I'm missing what's going on
> here. You found a problem with in-memory SQLite and then did or didn't
> solve it? Or you just worked around it?

Sorry for the confusion.

I worked around it. It's still an outstanding issue, I'm not that
familiar with the differences between using an in memory database and
using regular sqlite and have hit my limit on being able to track it.
I've also never ran the django test server using in memory sqlite
outside the test framework so I haven't figured out if this is a
general issue with the django test server or just with the test
framework+django test server.

Seeing the issue made me question why the framework defaulted to this
so I changed it in this patch and wrote in removal support for
regular sqlite (which didn't exist previously).

Note: I've added in some more comment and removed some old imports
from previous debugging, once I know where I should attach it this
will be in a new patch.

-Mikeal

[JP]

Mikeal Rogers wrote:
> > Excuse me for being very dense here, but I'm missing what's going on
> > here. You found a problem with in-memory SQLite and then did or didn't
> > solve it? Or you just worked around it?
>
> Sorry for the confusion.
>
> I worked around it. It's still an outstanding issue, I'm not that
> familiar with the differences between using an in memory database and
> using regular sqlite and have hit my limit on being able to track it.

I'd bet this is related to some issues I've seen in trying to get the
multi-db branch tests passing post r3661. The trouble is (or seems to
me to be) that anything that uses the test client causes the
request_finished signal to fire, which causes connection.close() to be
called, which makes the in-memory database go away, or at least lose
all of the tables, etc, that were populated into it during the
"request".

JP

[Russell Keith-Magee]

On 10/6/06, JP <jpel...@gmail.com> wrote:
>
> I'd bet this is related to some issues I've seen in trying to get the
> multi-db branch tests passing post r3661. The trouble is (or seems to
> me to be) that anything that uses the test client causes the
> request_finished signal to fire, which causes connection.close() to be
> called, which makes the in-memory database go away, or at least lose
> all of the tables, etc, that were populated into it during the
> "request".

r3723 added a modification to make connection.close() a no-op for
in-memory databases to address this exact problem. In my case, the
second test client test that was executed was failing because the
request_finished signal for the first test was closing the connection
and dropping tables.

It looks like this change has been merged into multi-db, so I can't
say I know why the tables would be dropped in your case.

Russ Magee %-)