Code

Opened 4 years ago

Closed 4 years ago

#12530 closed (wontfix)

Code in test classes can get access to live database

Reported by: Art_S Owned by: nobody
Component: Testing framework Version: 1.1
Severity: Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

When assigning fields in a test case class like this:

from django.test import TestCase

class TestClass(TestCase):

    field = [x for x in DataBaseObject.objects.all()]

The code is actually executed against "normal" database in settings.py, not the one which is temporarily created.
Possible workaround is to use property/lambda syntax.

Attachments (0)

Change History (3)

comment:1 Changed 4 years ago by russellm

  • Resolution set to wontfix
  • Status changed from new to closed

I acknowledge that this is a problem, but there really isn't anything we can do. A field defined like that will be instantiated when the class is loaded, which occurs before the test framework has a chance to redirect the database that is in use.

The other solution that you don't mention (and the solution that makes more sense to me anyway) is to set up the field in the setUp() method. During the call to setUp(), the test database will be in place. As an added bonus, setUp() is called at the start of every test run, guaranteeing that you won't have any artefact leakage between tests (i.e., test_1 modifies self.field, affecting the outcome of test_2).

Marking wontfix because there isn't really a fix, and the workaround is preferable to the problematic syntax.

comment:2 Changed 4 years ago by Art_S

  • Resolution wontfix deleted
  • Status changed from closed to reopened

I would like to re-open this.

My impression was that creation of instances of Test Classes was controlled by django.
If that's the case (only if!) then why can't it initialise the settings beforehand?

The whole thing is kind of dangerous - I can see the use case when you need to run the tests in production, and having any test code there which can potentially modify prod data is really bad.

comment:3 Changed 4 years ago by russellm

  • Resolution set to wontfix
  • Status changed from reopened to closed

We control the creation of test classes, but we don't control the way that Python parses code. The problem here is that the class-level property is instantiated when the class is parsed - which is when you test module is imported.

Please don't reopen tickets once they have been closed by a core developer or member of the triage team. If you disagree with a decision that has been made, open a discussion on the django-developers mailing list.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.