I am currently writing test cases for views, Which eventually uses database also.
By default a test database is being created and removed after test are run.
As the database itself is development database, I don't want my test to create a separate db but use exciting only.
Also I will like to bring to your notice, that in my environment, database are created and provided and django can't run migration or create database.
How can I create unittest which uses real database ?
I think the primary reason for this question is because your django database user is not provided with the create/drop database permission.
Django needs to create and drop a test database for the purpose of unit testing. It cannot use an existing database for this purpose. Why we are not allowed to use an existing database in the unit test is because, the data can be modified by anyone who has the same database permission and django may not have control over the updates they make, This might end up in an unsuccessful unit test.
This is clearly explained in another question's answer
If your DB Admin can provide your Django user the required access for the Test module to work as expected, You can make use of the Fixtures. Fixtures are like data files, can be created from your development environment and then can be used in the Unit test Setup to import the data from Fixtures to the test database created by Django.
The ultimate purpose of any Unit test framework will be to test the functionality of the Back end code logic with a data which is not likely to change. As mentioned in the above links, The Functional testing and Regression Testing is there to cover the real database.
For more details on Fixtures visit Using Fixtures with Django Test Cases
Related
Is there any way I can use my default local database for testing in Django 1.9. I also don't want to run any migrations, and I want to test it locally.
The reason I want to do it this way is that in my migrations, I have a data migration referring to some entry from a model and when tests run and create a test_database the migrations fail as there are no entries in the test model and this data migration use .get()
I don't know how I should resolve this issue. The best way I could think of is my default database for testing.
EDIT: The issue described below was caused not by bad workflow but by an apparent bug when loading fixtures. One of my apps had the fixture initial_data.json. The testing framework loads the fixture before performing the necessary migrations. (FWIW, I'm using Django 1.7 + python3.4) This issue is described here. (My workaround: rename the fixture to data.json.)
I'll leave the rest of the post intact in case this helps someone else in the future.
I'm trying to use Django's built-in tests to rapidly test my Django models during development. Unfortunately, when I try this, I get the error:
psycopg2.ProgrammingError: relation "app_relation" does not exist
The workflow I was imagining was
Define a few model fields (possibly across apps)
Test logic using Django tests
Fix logic errors, modify fields, and iterate this process.
This way, I can build my models incrementally without creating a large number of migrations. Migrations create headaches for me because I frequently add, remove, and rename fields or models as I'm validating my logic.
For example, my model has demographic fields, and I'm not sure whether I should keep an male_under_18 field or split it up into male_under_5, male_5_to_9, male_10_to_15, and male_16_to_18 granularity.
It sure would be nice to verify the decision using tests.py before making my migrations.
My understanding was that Django's manage.py test myapp created a database independent of the development database, and so doesn't require that my development database match the current schema defined by my models.
If the workflow above is impossible (or downright silly), I'm open to other ways to solving my problem.
Related question: django unit tests without a db. (Doesn't work because I want to test the DB!)
as explained in this question and in django docs, when using SimpleTestCase in unit testing, django should not create test database (which takes too long).
Inside one of my applications which is called "search, I have some unit test inherited from SimpleTestCase. this is tests.py inside search application:
class TokenizerTestCase(SimpleTestCase):
def test_one(self):
self.assertItemsEqual(1, 1)
When I call python manage.py test search.tests.TokenizerTestCase it takes too long to build default database. does anybody know why it is creating database for test?
By default SimpleTestCase creates a test database. You can extend the class for your own functionality. If you do not want to create a database of your own in each and every setup setup your own test environment extending the classes.
Override the _pre_setup and _post_teardown methods. For more information read the source code for TransactionTestCase to see how it creates the test database structure.
Read the source code here
Using Selenium within Django I'm trying to run 2 acceptance tests on my django app. The first test registers a new user of my app, the second one logs that user in to the system and tries to perform an action. However, when running the tests, between the first and second tests, the user is erased from the database. It seems the database is wiped between each test. All the documentation I have seen indicates this isn't supposed to be happening.
How can I prevent this from occurring?
Note: Both the setUpClass and tearDownClass methods of my Test Class have #classmethod decorators. Also, the browser doesn't close between the two tests running.
I am building a web interface for a database at my school. The database will hold our school's versions of academic standards.
When you build a site using django, does it create a clean database? For example, wysiwyg website builders like dreamweaver create ugly html and css code on the backend. I would hate to see a similar degree of auto-generated cruft in my database.
Should I create the database myself and then build a django site to access the database, or go ahead and let django create the database?
Under any simple to moderately complex application, Django will do a fine job creating the database for you. I've yet to run into any issues with what it's made.
I would suggest that you use South to handle your table migrations. And use virtualenv and pip to set up and maintain your Django environment.
You can use the sqlall predicate of manage.py to see the exact SQL that will be executed in order to generate the database.
Obviously django needs database tables for its basic functionality (contrib.apps).
Sure, you don't have to use them, but generally you want to use a least contrib.auth and some other bundled apps:
Each of these applications makes use
of at least one database table,
though, so we need to create the
tables in the database before we can
use them.
I any case you can't and shouldn't compare it to ugly html code generated by dreamweaver or word.
On a more abstract level:
One of key concepts of a web framework (following the mvc pattern) is that you define models which are "translated" (mapped) by the framework into database tables.
A model is the single, definitive
source of data about your data. It
contains the essential fields and
behaviors of the data you’re storing.
Generally, each model maps to a single
database table.
If you want to create the whole database scheme by hand you totally missed the point of using a web framework. In most cases you simply don't need to write sql manually. You define your classes and then you can query your objects using the builtin orm.