django tests. where to create users

[Gelonida N]

Hi,

I'd like to run some django tests, which use the test client and which
should check, that certain users can only access certain contents.

Where would you create this users / passwords.
- With a fixture
- as part of a test class in the SetUp section and tear
it down afterwards?

- create a custom test runner with a setup phase ?

Is there any other recommended code section, which could do the setup
prior to running tests.

Ideally I'd like to avoid fixtures.
Of course I could create a script to generate certain fixtures and run
only then the tests, but I'd prefer, the user data is created ad part of
the test procedure.

[Gelonida N]

I played a little more with django unit tests.

Django will reset the data base after each single test.

So it seems, I am stuck with fixtures at least at the moment I do not
know how to create users without fixtures such, that they would be
persistent between unit tests.

I really don't want to use fixtures, but some warm up code run only once
prior to running tests.

Any ideas?

[Mike Dewhirst]

On 29/11/2011 12:12pm, Gelonida N wrote:
> So it seems, I am stuck with fixtures at least at the moment I do not
> know how to create users without fixtures such, that they would be
> persistent between unit tests.
>

I agree - you are stuck. Perhaps a two tier approach might work. If you
bite the bullet and completely re-load the test database for every unit
test but use an in-memory sqlite it should run fairly quickly especially
if you have a mega-swag of RAM. Then once a week, switch to PostgreSQL
and leave them running while you go and have lunch.

Mike

[Tom Christie]

What's wrong with just creating them in the .setUp()?

Don't sweat the small amount of time it'll take to re-create the users on each test run, it's almost certainly not worth worrying about.

[Piotr Zalewa]

I use all solutions, depending on the needs.

When I'm testing a usage of many objects I use fixtures (also with users
as I'm "pretending" that users created them)

When there is a test involving a user I create this object, either in
test or the setUp.

On 11/28/11 01:58, Gelonida N wrote:
> Hi,
>
> I'd like to run some django tests, which use the test client and which
> should check, that certain users can only access certain contents.
>
> Where would you create this users / passwords.
> - With a fixture
> - as part of a test class in the SetUp section and tear
> it down afterwards?

There is no need to remove them
Just create a user in setUp if you need it for all tests, if for a part
of the tests only - create 2 test classes and create a user in one of
them only

> - create a custom test runner with a setup phase ?

I've got it as well - I don't create users there, but I've got a few
other methods which are useful for more than one app.

> Is there any other recommended code section, which could do the setup
> prior to running tests.
>
> Ideally I'd like to avoid fixtures.

Is there a reason?

> Of course I could create a script to generate certain fixtures and run
> only then the tests, but I'd prefer, the user data is created ad part of
> the test procedure.

zalun

[Gelonida N]

Well this is what I'm doing at the moment.
And I think you're right for this case:
Creating users will not be where a considerable amnount of time is
spent.

I'm just learning to use Django-testing / unit tests and as I could
imagine other setup activities which would consume more time
for setup I wanted to see whether there are ways to do some
programatical setup of 'fixtures' before the first test is run.

Basically I'd like to be sure I know my tools.

[Gelonida N]

On 11/29/2011 12:34 PM, Piotr Zalewa wrote:
> I use all solutions, depending on the needs.
>
> When I'm testing a usage of many objects I use fixtures (also with users
> as I'm "pretending" that users created them)
>
> When there is a test involving a user I create this object, either in
> test or the setUp.
>
> On 11/28/11 01:58, Gelonida N wrote:
>> Hi,
>>
>> I'd like to run some django tests, which use the test client and which
>> should check, that certain users can only access certain contents.
>>
>> Where would you create this users / passwords.
>> - With a fixture
>> - as part of a test class in the SetUp section and tear
>> it down afterwards?
>
> There is no need to remove them
> Just create a user in setUp if you need it for all tests, if for a part
> of the tests only - create 2 test classes and create a user in one of
> them only

Thanks. Yes I noticed meanhwile as well that the the database is reset
implicitely.

>
>> - create a custom test runner with a setup phase ?
>
> I've got it as well - I don't create users there, but I've got a few
> other methods which are useful for more than one app.
>

I mightl look at something like this.
If you midofied the database there, then would this become the initial
state for each test?
Reading the doc I assume yes.

>> Is there any other recommended code section, which could do the setup
>> prior to running tests.
>>
>> Ideally I'd like to avoid fixtures.
>
> Is there a reason?
>

Two reasons:

Migrations:
------------
Fixtures are rather sensitive to migrations
(so as part of the migration steps I had to regenerate them)

Lack pseudo randomness:
--------------------------
It's a question of taste, but I like a certain amount of controlled
randomness in my tests and data sets. (The idea is to log the random
seed in order to be able to reproduce failures)
So a test covers all the anticipated boundary cases (if the amount is
small enough) , but explores some others as well.
As soon a s a new killer data set is found it can be
added as a separate test (or fixture).