I have written tests for a Django project that i am working on, but one particular fixture fails to load.
The fixture is generated using dumpdata and i havent fiddled with it at all.
I can load the data using manage.py on that fixture without errors. I have verified that the data actually loaded using shell and querying the data.
This is driving me nuts, any help would be much appreciated.
Here is my test file (irrelevant portions removed):
class ViewsFromUrls(TestCase):
fixtures = [
'centers/fixtures/test_data.json',
'intranet/fixtures/test_data.json',
'training/fixtures/test_data.json', #The one that fails to load
]
def setUp(self):
self.c = Client()
self.c.login(username='USER', password='PASS')
...
def test_ViewBatch(self):
b = Batch.objects.all()[0].ticket_number
response = self.c.get(reverse('training.views.view_batch', kwargs={'id':b}))
self.assertTrue(response.status_code, 200)
...
Import the TestCase from django.test:
from django.test import TestCase
class test_something(TestCase):
fixtures = ['one.json', 'two.json']
...
Not: import unittest
Not: import django.utils.unittest
But: import django.test
That's a day of frustration right there.
Stop complaining - it's in the docs :-/
I Am not sure if this fixes your problem, but on this site:
https://code.djangoproject.com/wiki/Fixtures
I found an interesting remark:
you see that Django searches for appnames/fixtures and
settings.FIXTURE_DIRS and loads the first match. So if you use names
like testdata.json for your fixtures you must make sure that no other
active application uses a fixture with the same name. If not, you can
never be sure what fixtures you actually load. Therefore it is
suggested that you prefix your fixtures with the application names,
e.g. myapp/fixtures/myapp_testdata.json .
Applying this (renaming the fixtures with appname as prefix in the filename), solved my problem (I had the same issue as described here)
Check if the fixture is really in the right place. From the docs:
Django will search in three locations
for fixtures:
In the fixtures directory of every installed application
In any directory named in the FIXTURE_DIRS setting
In the literal path named by the fixture
One thing to note, when creating the FIXTURE_DIRS constant in your settings file, be sure to leave out the leading '/' if you have a general fixtures directory off of the root of your project.
Ex:
'/actual/path/to/my/app/fixtures/'
Now, in the settings.py file:
Will NOT work:
FIXTURE_DIRS = '/fixtures/'
Will work:
FIXTURE_DIRS = 'fixtures/'
It's possible this depends on how your other routes are configured, but it was a gotcha that had me scratching my head for a little while. Hope this is useful. Cheers.
A simple mistake I made was adding a custom setUpClass() and forgetting to include super().setUpClass() with it (which of course, is where Django's logic for loading fixtures lives)
Related
I am trying to run a TestCase on my model.
I already have a MySQL database (specifically MariaDB through a HeidiSQL GUI) created and connected with the respective data inside for this project.
My test.py code is as follows:
class TestArrivalProbabilities(TestCase):
def test_get_queryset_test(self):
print("Hello Steve!")
i = 1
self.assertEqual(i, 1)
l = [3, 4]
self.assertIn(4, l)
def test_get_queryset_again(self):
query_set = ArrivalProbabilities.objects.all()
print(query_set)
n = len(query_set)
print(n) # Print each row
bin_entries = []
bin_edges = []
for i in range(n):
print(query_set[i])
if query_set[i].binEntry is not None:
bin_entries.append(query_set[i].binEntry)
bin_edges.append(query_set[i].binEdge)
print(bin_entries, bin_edges)
hist = (numpy.array(bin_entries), numpy.array(bin_edges))
However, the output in the terminal is this:
(venv) C:\Users\Steve\uni-final-project>python manage.py test
Creating test database for alias 'default'...
System check identified no issues (0 silenced).
<QuerySet []>
0
[] []
.Hello Steve!
.
----------------------------------------------------------------------
Ran 2 tests in 0.016s
OK
Destroying test database for alias 'default'...
I have tried to figure out why the MySQL database I built isn't being used. I read up that Django creates a Test 'dummy database' to use on a test and then tears it down after but am I missing something really obvious?
I don't think it is a connection issue as I have pip installed mysqlclient. And I have tried to use the https://docs.djangoproject.com/en/3.2/topics/db/queries/#creating-objects but I still get the same result.
I have read the documentation but I am struggling with certain aspects of it as I am new to software development and this course is quite a steep learning curve.
I checked to see if this question wasn't asked before but I couldn't see any answers to it. Apologies in advance if it has been answered somewhere.
Any help in the right direction or a solution is much appreciated.
Thanks.
First of all you should read something related to testing not django's creating-objects. When you want to test your code usually there are some approaches regarding database. In official django documentation its shows how to deal with database instances. Simply when you start your test it creates a test database and runs your testcases. For that you can use a setUp function
add this and try again please:
class TestArrivalProbabilities(TestCase):
def setUp(self):
....
ArrivalProbabilities.objects.create(...)
ArrivalProbabilities.objects.create(...)
....
after this part you no longer will see empty queryset.
You can also use fixtures
I have achieved 100% test coverage in my application everywhere except my urls.py. Do you have any recommendations for how I could write meaningful unit tests for my URLs?
FWIW This question has arisen as I am experimenting with Test-Driven Development and want failing tests before I write code to fix them.
One way would be to reverse URL names and validate
Example
urlpatterns = [
url(r'^archive/(\d{4})/$', archive, name="archive"),
url(r'^archive-summary/(\d{4})/$', archive, name="archive-summary"),
]
Now, in the test
from django.urls import reverse
url = reverse('archive', args=[1988])
assertEqual(url, '/archive/1988/')
url = reverse('archive-summary', args=[1988])
assertEqual(url, '/archive-summary/1988/')
You are probably testing the views anyways.
Now, to test that the URL connect to the right view, you could use resolve
from django.urls import resolve
resolver = resolve('/summary/')
assertEqual(resolver.view_name, 'summary')
Now in the variable resolver (ResolverMatch class instance), you have the following options
'app_name',
'app_names',
'args',
'func',
'kwargs',
'namespace',
'namespaces',
'url_name',
'view_name'
Just complementing the answer from #karthikr (on the basis of his)
-> you may assert that the view in charge of resolve is the one you'd expect using resolver.func.cls
example
from unittest import TestCase
from django.urls import resolve
from foo.api.v1.views import FooView
class TestUrls(TestCase):
def test_resolution_for_foo(self):
resolver = resolve('/api/v1/foo')
self.assertEqual(resolver.func.cls, FooView)
Sorry for beeing a miner but I found this place as a first under key words "django url testing".
I fairly agree with my predecessors but I am also sure there is a better way to test your URLs. The main reason why we should not use "resolver = resolve('url/path')" is that the paths are of some kind fluent when the view's names are more fixed.
Well in simple words, this is better:
class TestUrls(TestCase):
def test_foo_url_resolves(self):
url = reverse('bar:foo')
self.assertEqual(resolve(url).func.view_class, FooBarView)
'bar:foo' - bar is a namespace and foo is a view name
than this
class TestUrls(TestCase):
def test_resolution_for_foo(self):
resolver = resolve('/api/v1/foo')
self.assertEqual(resolver.func.cls, FooView)
How do forcibly skip a unit test in Django?
#skipif and #skipunless is all I found, but I just want to skip a test right now for debugging purposes while I get a few things straightened out.
Python's unittest module has a few decorators:
There is plain old #skip:
from unittest import skip
#skip("Don't want to test")
def test_something():
...
If you can't use #skip for some reason, #skipIf should work. Just trick it to always skip with the argument True:
#skipIf(True, "I don't want to run this test yet")
def test_something():
...
unittest docs
Docs on skipping tests
If you are looking to simply not run certain test files, the best way is probably to use fab or other tool and run particular tests.
Django 1.10 allows use of tags for unit tests. You can then use the --exclude-tag=tag_name flag to exclude certain tags:
from django.test import tag
class SampleTestCase(TestCase):
#tag('fast')
def test_fast(self):
...
#tag('slow')
def test_slow(self):
...
#tag('slow', 'core')
def test_slow_but_core(self):
...
In the above example, to exclude your tests with the "slow" tag you would run:
$ ./manage.py test --exclude-tag=slow
I'm having trouble installing django-admin_action_mail from git.
I tried to install it via:
pip install
git+https://github.com/mjbrownie/django-admin_action_mail.git
But Django did not pick it up when I added it to settings.INSTALLED_APPS.
Did I miss something?
The admin code for that app is commented out (see here: https://github.com/mjbrownie/django-admin_action_mail/blob/master/admin_action_mail/admin.py ) so nothing is going to show up on the admin page - even if it's working and enabled.
It looks as though you need to create your own models to handle the mailing functions. Take a look at the README where it tells you to add something like the following in your app's admin.py:
from admin_action_mail.actions import mail_action
class MyModelAdmin(admin.ModelAdmin):
#Note all args are optional
actions = [
mail_action(
'description' : "Send Email to Related Users",
'email_dot_path' : 'email', # dot path string to email field (eg 'user.email')
'email_template_html' : 'admin_action_email/email.html'
'reply_to' : 'noreply#example.com' # defaults to request.user.email
)
]
admin.site.register(MyModel, MyModelAdmin)
Have you added a model like that to your own app's admin.py?
EDIT: As the problem appears to be with installation, the following should help:
You can add arbitrary paths to your wsgi path spec, that means it will pick up Python app modules in other locations. Assuming your app is installed in /home/user2161049/myapp you can put your external modules under /home/user2161049/myapp/external. In this case copy the contents of that app into /home/user2161049/myapp/external/admin_action_mail/.
To add this to your settings.py:
SITE_ROOT = os.path.dirname(os.path.realpath(__file__))
sys.path.append(os.path.join(SITE_ROOT, 'external'))
The first line defines SITE_ROOT based on the current running script (setup.py) at startup. The second adds the external folder into the search path. You can put anything you want in there, and even define a specific folder somewhere else if you want to keep your externals out of your app folder. Restart the server and it should find the app just fine.
I am trying to de-couple two apps:
Locations - app containing details about some location (town, country, place etc)
Directory - app containing details of places of interest (shop, railway station, pub, etc) - all categorised.
Both locations.Location and directory.Item contain lat/lng coords and I can find items within a certain distance of a specific lat/lng coord.
I'd like to use the following URL structure:
/locations/<location_slug>/directory/<category_slug>/
But I don't want to make my directory app reliant on my location app.
How can I translate this url to use a view like this in my directory app?
items_near(lat, lng, distance, category):
A work around would be to create a new view somewhere that translates this - but where should I put that? if it goes in the Directory app, then I've coupled that with my Location app, and vice versa.
Would a good idea be to place this workaround code inside my project URLs file? Thus keeping clear of both apps? Any issues with doing it like this?
For your urlpattern to work, the view function invoked has to be aware of both Locations and Directories. The short answer is you can put this view function anywhere you want - it's just a python function. But there might be a few logical places for it, outside of your Directory or Location app, that make sense.
First off, I would not put that view code in in your top-level urls.py, as that file is intended for URLconf related code.
A few options of where to put your view:
Create a new view function in a file that lives outside of any particular app. <project_root>/views.py is one possibility. There is nothing wrong with this view calling the item_near(..) view from the Directory app.
# in myproject/urls.py
urlpatterns = (
...
(r'/locations/(?P<location_slug>[\w\-]+)/directory/(?P<category_slug>[\w\-]+)/',
'myproject.views.items_near_from_slug')
)
# in myproject/views.py
from directory.views import items_near
def items_near_from_slug(request, location_slug, category_slug):
location = get_object_or_404(Location, slug=location_slug)
distance = 2 # not sure where this comes from
# And then just invoke the view from your Directory app
return items_near(request, location.lat, location.lng, distance, category_slug)
Create a new app and put the code there, in <my_new_app>/views.py. There is no requirement that a Django app need to have a models.py, urls.py, etc. Just make sure to include the __init__.py if you want Django to load the app properly (if, for instance, you want Django to automatically find templatetags or app specific templates).
Personally, I would go with option 1 only if the project is relatively simple, and <project_root>/views.py is not in danger of becoming cluttered with views for everything. I would go with option 2 otherwise, especially if you anticipate having other code that needs to be aware of both Locations and Directories. With option 2, you can collect the relevant urlpatterns in their own app-specific urls.py as well.
From the django docs here if you're using django >=1.1 then you can pass any captured info into the included application. So splitting across a few files:
# in locations.urls.py
urlpatterns = ('',
(r'location/(?P<location_slug>.*?)/', include('directory.urls')),
#other stuff
)
# in directory.urls.py
urlpatterns = ('',
(r'directory/(?P<directory_slug>.*?)/', 'directory.views.someview'),
#other stuff
)
# in directory.views.py
def someview(request, location_slug = None, directory_slug = None):
#do stuff
Hope that helps. If you're in django < 1.1 I have no idea.
Irrespective of how much ever "re-usable" you make your app, inevitably there is a need for site-specific code.
I think it is logical to create a "site-specific" application that uses the views of the reusable and decoupled apps.