I've got Django 1.4. In my test.py, I've got the requisite TestCase import:
from django.test import TestCase
To isolate the issue, I've added the line:
fixtures = ['westeros']
to the default example test case, i.e.
class SimpleTest(TestCase):
fixtures = ['westeros']
def test_basic_addition(self):
"""
Tests that 1 + 1 always equals 2.
"""
self.assertEqual(1 + 1, 2)
Using django-admin.py dumpdata, I created a fixture file called "westeros" in my customers/fixtures directory, where "customers" is an app that is listed in settings.INSTALLED_APPS.
When I run the test, at any verbosity, Django simply ignores the fixture and passes the test_basic_addition test. No error, no fixture loading. It's as if the TestCase import isn't there. Any ideas on what could be wrong or how to debug this?
It's ok to omit the extension when defining fixtures as you have done, i.e.
fixtures = ['westeros']
However, the fixture file itself must have the extension that corresponds to its serializer e.g westeros.json, westeros.json.zip or westeros.xml for json, zipped json or xml respectively.
Where is your westeros file located?
It needs to either be in a fixtures directory inside an app or in the dir specified by FIXTURE_DIRS in your settings.py file
You can run with tests with verbosity=2 to get full output.
https://docs.djangoproject.com/en/1.0/ref/django-admin/#test
Is your fixtures file named westeros ? or does it have a file extension?
Django will fail silently on fixture loads as you see. (at least up until 1.3, I haven't used fixtures in new 1.4 version yet). But you are not actually testing if the fixtures are loading.
Throw in a self.assertGreater(YourModel.objects.all(), 0) or somethign to verify that there are no objects, or drop in a debbuger and start querying some of your models.
Related
Using DJango/Python 3.7. I read here -- How do I run all Python unit tests in a directory? that I could use a "discover" command to find tests in a specified directory. I want to have a "tests" folder, so I cretaed one and then ran
(venv) localhost:myproject davea$ python -m unittest discover tests
Traceback (most recent call last):
File "/usr/local/Cellar/python/3.7.2_2/Frameworks/Python.framework/Versions/3.7/lib/python3.7/runpy.py", line 193, in _run_module_as_main
"__main__", mod_spec)
File "/usr/local/Cellar/python/3.7.2_2/Frameworks/Python.framework/Versions/3.7/lib/python3.7/runpy.py", line 85, in _run_code
exec(code, run_globals)
File "/usr/local/Cellar/python/3.7.2_2/Frameworks/Python.framework/Versions/3.7/lib/python3.7/unittest/__main__.py", line 18, in <module>
main(module=None)
File "/usr/local/Cellar/python/3.7.2_2/Frameworks/Python.framework/Versions/3.7/lib/python3.7/unittest/main.py", line 100, in __init__
self.parseArgs(argv)
File "/usr/local/Cellar/python/3.7.2_2/Frameworks/Python.framework/Versions/3.7/lib/python3.7/unittest/main.py", line 124, in parseArgs
self._do_discovery(argv[2:])
File "/usr/local/Cellar/python/3.7.2_2/Frameworks/Python.framework/Versions/3.7/lib/python3.7/unittest/main.py", line 244, in _do_discovery
self.createTests(from_discovery=True, Loader=Loader)
File "/usr/local/Cellar/python/3.7.2_2/Frameworks/Python.framework/Versions/3.7/lib/python3.7/unittest/main.py", line 154, in createTests
self.test = loader.discover(self.start, self.pattern, self.top)
File "/usr/local/Cellar/python/3.7.2_2/Frameworks/Python.framework/Versions/3.7/lib/python3.7/unittest/loader.py", line 344, in discover
raise ImportError('Start directory is not importable: %r' % start_dir)
ImportError: Start directory is not importable: 'tests'
This is odd to me because I have an (empty) init file ...
(venv) localhost:myproject davea$ ls web/tests/
__init__.py model_tests.py
What else do I need to do to get my test directory recognized?
Edit: Below are the contents of model_tests.py ...
from django.conf import settings
from django.test import TestCase
from django.core import management
def setup():
print("setup")
management.call_command('loaddata', 'test_data.yaml', verbosity=0)
def teardown():
management.call_command('flush', verbosity=0, interactive=False)
class ModelTest(TestCase):
# Verify we can correctly calculate the amount of taxes when we are working
# with a state whose tax rates are defined in our test data
def test_calculate_tax_rate_for_defined_state(self):
state = "MN"
income = 30000
taxes = IndividualTaxBracket.objects.get_taxes_owed(state, income)
print(taxes)
self.assertTrue(taxes > 0, "Failed to calucate taxes owed properly.")
I think you are having some confusion about discover command. According to docs.
Unittest supports simple test discovery. In order to be compatible
with test discovery, all of the test files must be modules or packages
(including namespace packages) importable from the top-level directory
of the project (this means that their filenames must be valid
identifiers).
It means all the test files must be importable from the directory from which you are running the command (directory that holds your web directory). It make this sure, all test files must be in valid python packages (directories containing __init__.py).
Secondly you are running the command python -m unittest discover tests which is wrong. You don't have to add tests at the end. unittests with discover command support 4 options. You can read more about it here.
I have following directory structure.
web
├── __init__.py
└── tests
├── __init__.py
└── test_models.py
And I am running following command.
python3 -m unittest discover
With following results.
...
----------------------------------------------------------------------
Ran 3 tests in 0.000s
OK
First things first: Having an __init__.py is not unusual, because the __init__.py tells python that the directory is a module; Its usual to have an empty __init__.py file. I had the same error, and fixed it by renaming my directory ..
Should a file named tests.py exist as a sibling of tests module, that would probably cause the mentioned ImportError, and removing test.py should fix it.
If still unit tests are not discovered, a couple of question are in order:
1) does the test module contain at least a class derived from django.test.TestCase ?
2) and in that case, does that class contain at least one method whose name starts with "test_"
Please note that the name of any file containing a unit test should start with "test".
So model_test.py will not work; is is generally used to setup some fake Models, but unit tests should reside elsewhere.
You can discover and run tests with this management command:
python manage.py test
or
python manage.py test appname
Is there any particular reason for using python -m unittest discover instead ? I think that could work either, but then you'll have to manually bootstrap the django environment
For completion ...
You already know that form here:
The names of your tests and files have to match a specific pattern in order to be discoverable by discover().
But then you got this error:
"django.core.exceptions.ImproperlyConfigured: Requested settings, but settings are not configured"
That means Django wasn't able to find its settings while running your tests. You can tell where to find settings using an environment variable:
DJANGO_SETTINGS_MODULE='myproyect.settings' python3 -m unittest discover
Reference: https://docs.djangoproject.com/en/2.2/topics/settings/#designating-the-settings
On the other hand ...
You should be running your Django tests with
./manage.py tests
this will search tests automatically using the same mechanism than discover(), and since you would be running a Django command, you will have some benefits against running the Django tests directly.
#Nafees Anwar asked: How does setting environment variable configure settings?
At the very beginning of the model_tests.py file there is the line from django.conf import settings, while creating the settings LazyObject instance, Django will search for that environment variable. Read the code for more detail.
I'll post here a snippet from that code for illustration.
# django.conf module.
ENVIRONMENT_VARIABLE = "DJANGO_SETTINGS_MODULE"
class LazySettings(LazyObject):
"""
A lazy proxy for either global Django settings or a custom settings object.
The user can manually configure settings prior to using them. Otherwise,
Django uses the settings module pointed to by DJANGO_SETTINGS_MODULE.
"""
def _setup(self, name=None):
"""
Load the settings module pointed to by the environment variable. This
is used the first time we need any settings at all, if the user has not
previously configured the settings manually.
"""
settings_module = os.environ.get(ENVIRONMENT_VARIABLE)
if not settings_module:
desc = ("setting %s" % name) if name else "settings"
raise ImproperlyConfigured(
"Requested %s, but settings are not configured. "
"You must either define the environment variable %s "
"or call settings.configure() before accessing settings."
% (desc, ENVIRONMENT_VARIABLE))
self._wrapped = Settings(settings_module)
So if you do:
from django.conf import settings
having that environment variable settled, the statement
settings.configure()
will fail with RuntimeError('Settings already configured.')
I have created an automation framework using toolium with Appium which works for both IOS and Android. Toolium is a python wrapper that I've used to facilitate page object modelling. Basically the UI is separated from the test case so that the same test case can be used across android as well as IOS.
I now need to get the framework working with IOS 10 (With XCUI test framework). So I have changed the elements for IOS so as to support XCUI (Places were XPATH is used and there is no other means of element identification). There is no change in the folder structure/execution mechanism whatsoever. But with the new framework I get an import error from toolium.
Code from tooling mobile page objects.py looks something like this.
# -*- coding: utf-8 -*-
import importlib
from toolium.driver_wrapper import DriverWrappersPool
from toolium.pageobjects.page_object import PageObject
class MobilePageObject(PageObject):
def __new__(cls, driver_wrapper=None):
"""Instantiate android or ios page object from base page object depending on driver configuration
Base, Android and iOS page objects must be defined with following structure:
FOLDER/base/MODULE_NAME.py
class BasePAGE_OBJECT_NAME(MobilePageObject)
FOLDER/android/MODULE_NAME.py
class AndroidPAGE_OBJECT_NAME(BasePAGE_OBJECT_NAME)
FOLDER/ios/MODULE_NAME.py
class IosPAGE_OBJECT_NAME(BasePAGE_OBJECT_NAME)
:param driver_wrapper: driver wrapper instance
:returns: android or ios page object instance
"""
if cls.__name__.startswith('Base'):
__driver_wrapper = driver_wrapper if driver_wrapper else DriverWrappersPool.get_default_wrapper()
__os_name = 'ios' if __driver_wrapper.is_ios_test() else 'android'
__class_name = cls.__name__.replace('Base', __os_name.capitalize())
try:
return getattr(importlib.import_module(cls.__module__), __class_name)(__driver_wrapper)
except AttributeError:
__module_name = cls.__module__.replace('.base.', '.{}.'.format(__os_name))
print __module_name
print __class_name
print __driver_wrapper
return getattr(importlib.import_module(__module_name), __class_name)(__driver_wrapper)
else:
return super(MobilePageObject, cls).__new__(cls)
I follow the folder structure as mentioned in toolium. Basically I have,
pageobjects folder under which I have base folder, ios folder and android folder. All my methods are in the base class. The elements are picked up either from the iOS folder or android folder at run time based on the driver type.
Below is the error from the import module
name = 'pageobjects.ios.intro', package = None
def import_module(name, package=None):
"""Import a module.
The 'package' argument is required when performing a relative import. It
specifies the package to use as the anchor point from which to resolve the
relative import to an absolute import.
"""
if name.startswith('.'):
if not package:
raise TypeError("relative imports require the 'package' argument")
level = 0
for character in name:
if character != '.':
break
level += 1
name = _resolve_name(name[level:], package, level)
__import__(name)
E ImportError: No module named ios.intro
When I print the module name and class name this is what I get.
module name = pageobjects.ios.intro
class name = IosIntroduction
intro is one of the modules basically. I access it something like this
from pageobjects.base.intro import BaseIntroduction
On the same machine I have the old framework working without any problem. I have checked environment variables/permissions etc. But I can't seem to figure out as to why the import is failing.
PS: I am running this on MACOSX and also use virtualenvironment for python
On upgrading to Django 1.7 I'm getting the following error message from ./manage.py
$ ./manage.py
Traceback (most recent call last):
File "./manage.py", line 16, in <module>
execute_from_command_line(sys.argv)
File "/home/johnc/.virtualenvs/myproj-django1.7/local/lib/python2.7/site-packages/django/core/management/__init__.py", line 427, in execute_from_command_line
utility.execute()
File "/home/johnc/.virtualenvs/myproj-django1.7/local/lib/python2.7/site-packages/django/core/management/__init__.py", line 391, in execute
django.setup()
File "/home/johnc/.virtualenvs/myproj-django1.7/local/lib/python2.7/site-packages/django/__init__.py", line 21, in setup
apps.populate(settings.INSTALLED_APPS)
File "/home/johnc/.virtualenvs/myproj-django1.7/local/lib/python2.7/site-packages/django/apps/registry.py", line 89, in populate
"duplicates: %s" % app_config.label)
django.core.exceptions.ImproperlyConfigured: Application labels aren't unique, duplicates: foo
What's the problem and how do I resolve it?
The problem is that with the changes to apps in Django 1.7, apps are required to have a unique label.
By default the app label is the package name, so if you've got a package with the same name as one of your app modules (foo in this case), you'll hit this error.
The solution is to override the default label for your app, and force this config to be loaded by adding it to __init__.py.
# foo/apps.py
from django.apps import AppConfig
class FooConfig(AppConfig):
name = 'full.python.path.to.your.app.foo'
label = 'my.foo' # <-- this is the important line - change it to anything other than the default, which is the module name ('foo' in this case)
and
# foo/__init__.py
default_app_config = 'full.python.path.to.your.app.foo.apps.FooConfig'
See https://docs.djangoproject.com/en/1.7/ref/applications/#for-application-authors
I found simple solution for this. In my case following line is added twice under INSTALLED_APPS,
'django.contrib.foo',
Removed one line fixes the issue for me.
I had the same error - try this:
In INSTALLED_APPS, if you are including 'foo.apps.FooConfig', then Django already knows to include the foo app in the application, there is therefore no need to also include 'foo'.
Having both 'foo' and 'foo.apps.FooConfig' under INSTALLED_APPS could be the source of your problem.
Well, I created a auth app, and included it in INSTALLED_APP like src.auth (because it's in src folder) and got this error, because there is django.contrib.auth app also. So I renamed it like authentication and problem solved!
I got the same problem.
Here my app name was chat and in the settings.py , under installed apps i have written chat.apps.ChatConfig while i have already included the app name chat at the bottom. When i removed the chat.apps.ChatConfig mine problem was solved while migrations. This error may be due to the same instance that you might have defined you app name foo twice in the settings.py. I hope this works out!!
please check if anything is duplicated in INSTALLED_APPS of settings.py
This exception may also be raised if the name of the AppConfig class itself matches the name of another class in the project. For example:
class MessagesConfig(AppConfig):
name = 'mysite.messages'
and
class MessagesConfig(AppConfig):
name = 'django.contrib.messages'
will also clash even though the name attributes are different for each configuration.
In previous answer 'django.contrib.foo', was mentioned, but basically adding any app twice can cause this error just delete one (Django 3.0)
for me it was in settings.py
INSTALLED_APPS = [
...
'accounts.apps.AccountsConfig',
'accounts.apps.AccountsConfig',
...
]
just delete one of them
Basically this problem has been created due to duplication of name of installed app in the settings:
This is how I resolved the problem. In settings.py file:
Check the install app in the setting.py if the install app are duplicate
Error shown due to duplication of app name
Remove the duplicate name in the install file
After problem is resolved, you will see interface in your screen
For this I have created application name as polls instead of foo
As therefromhere said this is a new Django 1.7 feature which adds a kind of “app registry” where applications must be determined uniquely (and not only having different python paths).
The name attribute is the python path (unique), but the label also should be unique. For example if you have an app named 'admin', then you have to define the name (name='python.path') and a label which must be also unique (label='my admin' or as said put the full python path which is always unique).
Had same issue, read through the settings.py of the root folder, removed any INSTALLED APPS causing conflict... works fine. Will have to rename the apps names
Need to check in two file
1- apps.py
code something like
from django.apps import AppConfig
from django.utils.translation import ugettext_lazy as _
class ModuleConfig(AppConfig):
name = "ocb.module_name"
verbose_name = _("Module Name")
2 - init.py
code something like
default_app_config = "ocb.users.apps.ModuleConfig"
default_app_config is pointed to your apps.py's class name
in my case, in mysite settings.py , in INSTALLED_APPS array variable I put the name of the app twice by mistake.
I had almost the same issue.
```File "/Users/apples/.local/share/virtualenvs/ecommerce-pOPGWC06/lib/python3.7/site-packages/django/apps/registry.py", line 95, in populate
"duplicates: %s" % app_config.label)
django.core.exceptions.ImproperlyConfigured: Application labels aren't unique, duplicates: auth```
I had installed Django.contrib.auth twice. I removed one and it worked well.
From my experience, this exception was masking the real error. To see the real error (which in my case was an uninstalled python package) comment out the following in django/apps/registry.py:
if app_config.label in self.app_configs:
# raise ImproperlyConfigured(
# "Application labels aren't unique, "
# "duplicates: %s" % app_config.label)
pass
Check for duplicates in INSTALLED_APPS inside the settings.py...If so remove one of it and rerun the command
I had Django==3.2.9 when tried to test my existing Django app on a new environment. I had this exact issue and fixed it by downgrading to Django==3.1.13.
There seems to be an update to applications, check the Django 3.2 documentation for detailed information.
This error occurs because of duplication in your INSTALLED_APPS in settings.py file which is inside your project.
For me, the problem was that I had copy-pasted entire app instead of creating it using command line. So, the app name in the apps.py file was same for 2 apps. After I corrected it, the problem was gone.
In case if you have added your app name in settings.py
example as shown in figure than IN settings.py Remove it and Try this worked for me.
give it a try .
This Worked Because settings.py assumes installing it twice and does not allow for migration
If you want to back older version, command
pip install django==1.6.7
I am learning test driven development...
I wrote a test that should fail but it's not...
(env)glitch:ipals nathann$ ./manage.py test npage/
Creating test database for alias 'default'...
----------------------------------------------------------------------
Ran 0 tests in 0.000s
OK
Destroying test database for alias 'default'...
in npage/ I have tests.py:
from django.test import TestCase
from npage.models import Tip
import datetime
# Example
class TipTester(TestCase):
def setUp(self):
print dir(self)
Tip.objects.create(pk=1,
text='Testing',
es_text='Probando')
def tips_in_spanish(self):
my_tip = Tip.objects.get(pk=1)
my_tip.set_language('es')
self.assertEqual(my_tip.text, 'this does not just say \'Probando\'')
What am I doing wrong? I've read this but I still can't figure out what is going wrong here.
Your test functions need to start with test:
def test_tips_in_spanish(self):
Docs here
"When you run your tests, the default behavior of the test utility is to find all the test cases (that is, subclasses of unittest.TestCase) in any file whose name begins with test, automatically build a test suite out of those test cases, and run that suite."
If I run the following command:
>python manage.py test
Django looks at tests.py in my application, and runs any doctests or unit tests in that file. It also looks at the __ test __ dictionary for extra tests to run. So I can link doctests from other modules like so:
#tests.py
from myapp.module1 import _function1, _function2
__test__ = {
"_function1": _function1,
"_function2": _function2
}
If I want to include more doctests, is there an easier way than enumerating them all in this dictionary? Ideally, I just want to have Django find all doctests in all modules in the myapp application.
Is there some kind of reflection hack that would get me where I want to be?
I solved this for myself a while ago:
apps = settings.INSTALLED_APPS
for app in apps:
try:
a = app + '.test'
__import__(a)
m = sys.modules[a]
except ImportError: #no test jobs for this module, continue to next one
continue
#run your test using the imported module m
This allowed me to put per-module tests in their own test.py file, so they didn't get mixed up with the rest of my application code. It would be easy to modify this to just look for doc tests in each of your modules and run them if it found them.
Use django-nose since nose automatically find all tests recursivelly.
Here're key elements of solution:
tests.py:
def find_modules(package):
"""Return list of imported modules from given package"""
files = [re.sub('\.py$', '', f) for f in os.listdir(os.path.dirname(package.__file__))
if f.endswith(".py") and os.path.basename(f) not in ('__init__.py', 'test.py')]
return [imp.load_module(file, *imp.find_module(file, package.__path__)) for file in files]
def suite(package=None):
"""Assemble test suite for Django default test loader"""
if not package: package = myapp.tests # Default argument required for Django test runner
return unittest.TestSuite([doctest.DocTestSuite(m) for m in find_modules(package)])
To add recursion use os.walk() to traverse module tree and find python packages.
Thanks to Alex and Paul. This is what I came up with:
# tests.py
import sys, settings, re, os, doctest, unittest, imp
# import your base Django project
import myapp
# Django already runs these, don't include them again
ALREADY_RUN = ['tests.py', 'models.py']
def find_untested_modules(package):
""" Gets all modules not already included in Django's test suite """
files = [re.sub('\.py$', '', f)
for f in os.listdir(os.path.dirname(package.__file__))
if f.endswith(".py")
and os.path.basename(f) not in ALREADY_RUN]
return [imp.load_module(file, *imp.find_module(file, package.__path__))
for file in files]
def modules_callables(module):
return [m for m in dir(module) if callable(getattr(module, m))]
def has_doctest(docstring):
return ">>>" in docstring
__test__ = {}
for module in find_untested_modules(myapp.module1):
for method in modules_callables(module):
docstring = str(getattr(module, method).__doc__)
if has_doctest(docstring):
print "Found doctest(s) " + module.__name__ + "." + method
# import the method itself, so doctest can find it
_temp = __import__(module.__name__, globals(), locals(), [method])
locals()[method] = getattr(_temp, method)
# Django looks in __test__ for doctests to run
__test__[method] = getattr(module, method)
I'm not up to speed on Djano's testing, but as I understand it uses automatic unittest discovery, just like python -m unittest discover and Nose.
If so, just put the following file somewhere the discovery will find it (usually just a matter of naming it test_doctest.py or similar).
Change your_package to the package to test. All modules (including subpackages) will be doctested.
import doctest
import pkgutil
import your_package as root_package
def load_tests(loader, tests, ignore):
modules = pkgutil.walk_packages(root_package.__path__, root_package.__name__ + '.')
for _, module_name, _ in modules:
try:
suite = doctest.DocTestSuite(module_name)
except ValueError:
# Presumably a "no docstrings" error. That's OK.
pass
else:
tests.addTests(suite)
return tests