On 9/4/06, Matthew Flanagan <[EMAIL PROTECTED]> wrote:
and use ./manage.py --settings=myapp.testsettings.I briefly considered this approach when the TEST_DATABASE_NAME suggestion came up. However, I was concered about the possibility for accidentally nuking your production database. If you ever for
Russell Keith-Magee wrote:
> On 9/4/06, Ned Batchelder <[EMAIL PROTECTED]> wrote:
>> Partly on this topic: I would very much like to use sqlite in-memory
>> databases for testing, even though I use MySQL for deployment. The speed
>> difference is 10x. One way to do this is to have a TEST_DATAB
Matthew Flanagan wrote:
On 04/09/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
On 9/4/06, Ned Batchelder <[EMAIL PROTECTED]> wrote:
Partly on this topic: I would very much like to use sqlite in-memory
databases for testing, even though I use
On 04/09/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
>
>
> On 9/4/06, Ned Batchelder <[EMAIL PROTECTED]> wrote:
> >
> >
> > Partly on this topic: I would very much like to use sqlite in-memory
> databases for testing, even though I use MySQL for deployment. The speed
> difference is 10x.
Russell Keith-Magee wrote:
On 9/4/06, Ned Batchelder
<[EMAIL PROTECTED]>
wrote:
Partly on this topic: I
would very much like to use sqlite in-memory
databases for testing, even though I use MySQL for deployment. The
speed difference is 10x. One way to do this is to have a
TEST
On 9/4/06, Ned Batchelder <[EMAIL PROTECTED]> wrote:
Partly on this topic: I would very much like to use sqlite in-memory
databases for testing, even though I use MySQL for deployment. The
speed difference is 10x. One way to do this is to have a
TEST_DATABASE_ENGINE setting, and add logi
Partly on this topic: I would very much like to use sqlite in-memory
databases for testing, even though I use MySQL for deployment. The
speed difference is 10x. One way to do this is to have a
TEST_DATABASE_ENGINE setting, and add logic to create_test_db().
Thoughts?
--Ned.
Adrian Holovat
On 9/1/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> In Michael's case, it sounds like test_myapplication would never be a viable
> database name (due to some name clash). Given that he knows this, and it
> will be a persistent condition, asking him to type './manage.py
> --test_db_name="no
On 9/1/06, Adrian Holovaty <[EMAIL PROTECTED]
> wrote:
Any particular reason you used a setting instead of a simplecommand-line parameter? In my view, we should only be adding settingsif absolutely necessary.I agree that a command line argument would probably be viable if the problem was restricted
On 9/1/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> These are reasonable concerns. I have just committed (r3706) a
> TEST_DATABASE_NAME setting; by default, this has a value of None, which will
> cause the test database to use the same 'test_' + DATABASE_NAME scheme;
> however, if you prov
On 9/1/06, Michael Radziej <[EMAIL PROTECTED]> wrote:
I can work around this, sure, but I'd propose to allow tooverwrite the default test database name for the test suite
somehow, preferably on the command line of runtests.py.Thanks for the feedback. These are reasonable concerns. I have just commi
Hi,
I'm checking out the changes from the last three weeks in svn ...
seems like the test suite is a little bit different now ;-)
I can't say much about it now other than I appreciate all the
hard work by Russell, and that there's a nice test framework in
place now.
Only ... I find the naming o
12 matches
Mail list logo
