Re: parallel test running throwing pickleError

rote: >>> >>> Hi Girish, >>> >>> I think you didn't to install the `tblib` package[1]. >>> >>> Cheers, >>> Simon >>> >>> [1] >>> https://docs.djangoproject.com/en/1.9/ref/django-admin/#cmdoption-test--parallel >

Re: parallel test running throwing pickleError

February 29, 2016 at 11:07:37 PM UTC+5:30, Simon Charette wrote: >> >> Hi Girish, >> >> I think you didn't to install the `tblib` package[1]. >> >> Cheers, >> Simon >> >> [1] >> https://docs.djangoproject.com/en/1.9/ref/django-admin/#

Re: Test fails when run in whole test suite - but not stand-alone?

I have no immediate clue. I know that, using nosetest, I can add -s and -v to the command line, making it possible to drive pdb from the test, using: import pdb;pdb.set_trace() inserted in the code to get into pdb at the relevant point(s). Evan if you're not running under nosetest

Re: Test fails when run in whole test suite - but not stand-alone?

Hi Adam I have narrowed the issue right down. As soon as I have even *one* other test that imports *anything* from the app's admin file, the test crashes. So for example, if the test sequence is group of test files - one of which is my one in the OP and one which contains: import unittest

Re: Stripe Not Returning Token (test mode)

w-remember-me="true" > > data-email="{{ summary_dict.email_address }}" > > data-locale="auto" > > data-label="Register with Card" > > data-zip-code="true"> > > > > > > --

Re: Stripe Not Returning Token (test mode)

" data-zip-code="true"> From: "Chris Kavanagh" <cka...@gmail.com> To: "Digest Recipients" <django-users@googlegroups.com> Sent: Friday, June 17, 2016 8:51:04 PM Subject: Re: Stripe Not Returning Token (test mode) One last question, if you d

Re: Stripe Not Returning Token (test mode)

> *From: *"Chris Kavanagh" <cka...@gmail.com> > *To: *"Django users" <django-users@googlegroups.com> > *Sent: *Thursday, June 16, 2016 2:20:22 PM > *Subject: *Stripe Not Returning Token (test mode) > > *Stripe Not Returning Token (test mode)* &g

Re: Stripe Not Returning Token (test mode)

stomer = stripe.Customer.create( >> description=summary_dict['email_address'], >> source=token >> ) >> >> >> -- >> *From: *"Chris Kavanagh" <cka...@gmail.com> >> *To: *&q

Re: Stripe Not Returning Token (test mode)

r = stripe.Customer.create( > description=summary_dict['email_address'], > source=token > ) > > > -- > *From: *"Chris Kavanagh" <cka...@gmail.com> > *To: *"Django users" <django-users@googlegroups.com> &g

Re: Stripe Not Returning Token (test mode)

r = stripe.Customer.create( > description=summary_dict['email_address'], > source=token > ) > > > -- > *From: *"Chris Kavanagh" <cka...@gmail.com> > *To: *"Django users" <django-users@googlegroups.com> &g

Re: Stripe Not Returning Token (test mode)

'], source=token ) From: "Chris Kavanagh" <cka...@gmail.com> To: "Django users" <django-users@googlegroups.com> Sent: Thursday, June 16, 2016 2:20:22 PM Subject: Stripe Not Returning Token (test mode) Stripe Not Returning Token (test mode) I'm trying out S

Stripe Not Returning Token (test mode)

*Stripe Not Returning Token (test mode)* I'm trying out Stripe in test mode on a site I'm building, and for some reason Stripe won't return a token as it's supposed to. I can tell it's not returning a token, because I get a MultiValueDictKeyError when submitting the form. Plus, it won't print

Re: Test fails when run in whole test suite - but not stand-alone?

Hi Adam, I was hitting same issue but never got chance to debug it. If the underneath database support database transactions then isn't that each test will be treated as a separate transaction and transaction should be rolled back after the test is over to keep the database sane ? On Wednesday

Test cases are always referring to default database in case of Multiple databases

Hi, I am trying to run some test cases on one of the apps of my Django Project. My settings.py file specifies two different databases as follows: DATABASES = { 'default': { 'ENGINE': 'django.db.backends.sqlite3', 'NAME': os.path.join(BASE_DIR, 'db.sqlite3

Re: Test fails when run in whole test suite - but not stand-alone?

Thanks Adam, I will try that. I think I have been lax in the use of tearDown. On Thursday, 2 June 2016 21:47:00 UTC+2, Adam wrote: > > When I've had that happen before, it's because some previous test changed > something (like a setting value or the site domain) that influenced th

Re: Test fails when run in whole test suite - but not stand-alone?

When I've had that happen before, it's because some previous test changed something (like a setting value or the site domain) that influenced the test that failed. To narrow it down, I would run all the tests up to and including the failed one. That should fail, then I start taking out half

Test fails when run in whole test suite - but not stand-alone?

I have a test that is failing when the file it is in is run as part of all the other test files by the test runner. If I just run only the file that contains this test - then it passes. (pass/fail refers to the very last assert in the code below.) I'd appreciate any ideas or insights from

Django Test Errors

test_*.py >test_views/ > __init__.py > test_*.py >test_forms/ >test_*.py >__init__.py And in those init files I include all of the test_*.py files. Anyway, In my tests, I have a few mock classes inside of a test file of tes

Re: Test runner wants to run models package?!

Hallöchen! Tim Graham writes: > Could you try Python 3.4.x? The problem does not exist with Python 3.4.3. (Ubuntu 14.04) > I ran into some issues with Django's own test suite [0] due to > some import changes in Python 3.5 [1]. If I look at Python 3.5's release notes, the

Re: Test runner wants to run models package?!

Could you try Python 3.4.x? I ran into some issues with Django's own test suite [0] due to some import changes in Python 3.5 [1]. [0] https://code.djangoproject.com/ticket/23763#comment:11 [1] http://bugs.python.org/issue7559 On Tuesday, April 26, 2016 at 6:04:56 PM UTC-4, Torsten Bronger wrote

Test runner wants to run models package?!

Hallöchen! With Django 1.9.5 (rest are original Ubuntu 16.04 packages) and Python 3.5.1, "manage.py test myapp" tries to run the *models* package of myapp as a test module: user@localhost:~/src/myproject/myproject$ ./manage.py test myapp --pattern=invalid_pattern Creating tes

Re: Running Django-Test fails with TransactionManagementError

Glad to hear it, sorry I wasn't more help. On Fri, Apr 15, 2016 at 10:49 AM, <schaf...@gmail.com> wrote: > Hey John, > cool it runs now. > I had multiple problems: > > 1.) I granted ALL rights to my user on the test DB. > ==> This solved the issue with the Transactio

Re: Running Django-Test fails with TransactionManagementError

Hey John, cool it runs now. I had multiple problems: 1.) I granted ALL rights to my user on the test DB. ==> This solved the issue with the TransactionManagementError. 2.) I had to do some changes in my configuration and play around. Afterwards the tests were running. But not all gr

Re: Running Django-Test fails with TransactionManagementError

No I have not added a target. The reason is that there is a class deriving from NoseTestSuiteRunner. This class defines the run_tests function which modifies the test_labels passed to the base 'constructor'. If I add a Target for a single test (testclass.testMethod) then just this test method

Re: Running Django-Test fails with TransactionManagementError

; As a development environment I use PyCharm. >>>>> As I wanted to run the unit tests I created a new run/debug >>>>> configuration. >>>>> I did not add any Target. Just the Environment variable for >>>>> DJANGO_SETTINGS_MODULE and a working d

Re: Running Django-Test fails with TransactionManagementError

nner.py. >>>> As a development environment I use PyCharm. >>>> As I wanted to run the unit tests I created a new run/debug >>>> configuration. >>>> I did not add any Target. Just the Environment variable for >>>> DJANGO_SETTINGS_MODULE and a working dir

Re: Running Django-Test fails with TransactionManagementError

t; As I wanted to run the unit tests I created a new run/debug >>> configuration. >>> I did not add any Target. Just the Environment variable for >>> DJANGO_SETTINGS_MODULE and a working directory. >>> >>> But when I run/debug the tests, I always get a >>

Re: Running Django-Test fails with TransactionManagementError

and a working directory. >> >> But when I run/debug the tests, I always get a >> 'TransactionManagementError: Transaction managed block ended with pending >> COMMIT/ROLLBACK >> It also say that no tests were found but the test DB was created. >> Do you have any hints?

Re: Running Django-Test fails with TransactionManagementError

ion. > I did not add any Target. Just the Environment variable for > DJANGO_SETTINGS_MODULE and a working directory. > > But when I run/debug the tests, I always get a > 'TransactionManagementError: Transaction managed block ended with pending > COMMIT/ROLLBACK > It also say that no

Running Django-Test fails with TransactionManagementError

that no tests were found but the test DB was created. Do you have any hints? Connected to pydev debugger (build 141.1899) /home/schaf/workspace/Solution/env/bin/python /home/schaf/Schreibtisch/ pycharm-4.5.3/helpers/pydev/pydevd.py --multiproc --client 127.0.0.1 --port 60525 --file /home/schaf

Re: Django capser headless test and jenkins

thub.com/dobarkod/django-casper in a jenkins job. Basically > what I > > need in my jenkins job is: > > > > clone latest version of my django web app > > Install django (e.g. in a Python virtual env. in the workspace) > > Start django web server hosting my w

Re: Django capser headless test and jenkins

e) > Start django web server hosting my web app > Run casper headless test > Report result > Stop/remove django web server > > Are there any recommended approaches to doing the above; automatically > start, test and stop a django web server? I would like to keep apache > configu

Automating install, start, test and shutdown of django web application?

) 3) Start django web server hosting my django web app 4) Run casper headless tests 5) Generate test report 6) Shutdown/remove django webserver/web application. What are the recommended workflow for the above; automatically install, start, test and shutdown a django web application/web server? I

Django capser headless test and jenkins

. Start django web server hosting my web app 4. Run casper headless test 5. Report result 6. Stop/remove django web server Are there any recommended approaches to doing the above; automatically start, test and stop a django web server? I would like to keep apache configuration out

Why I can not run my test, namely my custom apps with django-nose?

' *Command: *./manage.py test apps *Content apps/app_accounts/apps.py* from django.apps import AppConfig class AppAccountsConfig(AppConfig): name = 'apps.app_accounts' verbose_name = 'Application for accounts' *Content apps/app_accounts/models.py* import imghdr import string import datetime

Re: how to run migrations in a specific order for the test runner in Django (1.6+)

o tell django test runner to run migrations in a certain > order? > > Sidi > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+

how to run migrations in a specific order for the test runner in Django (1.6+)

is there a way to tell django test runner to run migrations in a certain order? Sidi -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-user

Re: Test Client response.json() UnicodeDecodeError

ine > 13, in _curried > return _curried_func(*(args + moreargs), **dict(kwargs, **morekwargs)) > File ".../lib/python2.7/site-packages/django/test/client.py", line 662, > in _parse_json > return json.loads(response.content.decode(), **extra) > UnicodeDecodeError: 'a

Test Client response.json() UnicodeDecodeError

_curried return _curried_func(*(args + moreargs), **dict(kwargs, **morekwargs)) File ".../lib/python2.7/site-packages/django/test/client.py", line 662, in _parse_json return json.loads(response.content.decode(), **extra) UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in posit

Re: parallel test running throwing pickleError

) wheel (0.24.0) wmctrl (0.3) On Monday, February 29, 2016 at 11:07:37 PM UTC+5:30, Simon Charette wrote: > > Hi Girish, > > I think you didn't to install the `tblib` package[1]. > > Cheers, > Simon > > [1] > https://docs.djangoproject.com/en/1.9/ref/django-admin/#c

Re: parallel test running throwing pickleError

Hi Girish, I think you didn't to install the `tblib` package[1]. Cheers, Simon [1] https://docs.djangoproject.com/en/1.9/ref/django-admin/#cmdoption-test--parallel Le lundi 29 février 2016 12:13:08 UTC-5, girish ramnani a écrit : > > when running the django test in parallel

parallel test running throwing pickleError

when running the django test in parallel using the runner.py . _pickle.PicklingError: Can't pickle : attribute lookup ModuleImportFailure on unittest.loader failed error is thrown, and when the runner is run using a single process. the test suite executes. I am using a new virtualenv

How does one initialise a test database exactly as one wishes?

I have a project (using Django 1.8) where I want to initialise a test database with some fixture data obtained from doing a manage.py dumpdata from a development instance of the database (with an identical schema to the test database). The fixture data contains *everything* in the source

AttributeError When Overwritting AUTH_USER_MODEL in Test Cases

Hello, When I override the AUTH_USER_MODEL setting to "auth.User", when AUTH_USER_MODEL in settings is not set to "auth.User", in either a TestCase or individual test, and then try to access the objects attribute on the user model, I get an AttributeError. T

Re: How should it make django test create a default_test database that is using 5 shemas ?

Ok thanks , make sense , 'ill try to do that thank you > > > > > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To

Re: How should it make django test create a default_test database that is using 5 shemas ?

On Fri, Jan 29, 2016 at 02:50:07PM -0800, JAMES DAMILD ETIENNE wrote: > I have a possgres database with 5 shemas , it connects very well to it , > but when truing to do unit test on my models or view , the default table > created in sqllite3 is saysing that on of

Re: How should it make django test create a default_test database that is using 5 shemas ?

> > any help please ? > thank you > On Friday, January 29, 2016 at 6:31:17 PM UTC-5, JAMES DAMILD ETIENNE wrote: > > I have a possgres database with 5 shemas , it connects very well to it , > but when truing to do unit test on my models or view , the default table

how to run django test with a default test database , while the real database is a posgres with 5 shemas ?

any help please ? -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to

How should it make django test create a default_test database that is using 5 shemas ?

I have a possgres database with 5 shemas , it connects very well to it , but when truing to do unit test on my models or view , the default table created in sqllite3 is saysing that on of my table is not there : return Database.Cursor.execute(self, query, params) OperationalError

Re: How to view the generated SQL for test models?

mells a bit like your test models don't get imported early enough to > be fully initialized before database creation happens. And this might be > caused precisely by the fact that your models are not inside models.py. Having no SQL to look at, made the debugging slightly tedious,

Re: How to view the generated SQL for test models?

a bit like your test models don't get imported early enough to be fully initialized before database creation happens. And this might be caused precisely by the fact that your models are not inside models.py. Having no SQL to look at, made the debugging slightly tedious, but I found

Re: How to view the generated SQL for test models?

oblem you are solving. > > > > I have an app, that defines a couple of *abstract models* and *mixins* in > it's `models.py`, that are only used in other apps. > > To test those abstract models and mixins I created concrete models (from > `django.db.models.Model`), that use the

Re: How to view the generated SQL for test models?

and *mixins* in it's `models.py`, that are only used in other apps. To test those abstract models and mixins I created concrete models (from `django.db.models.Model`), that use these abstract models and mixins, in `test.py`. I created them in `test.py`, so that the test models don't get created in th

Re: How to view the generated SQL for test models?

and *mixins* in it's `models.py`, that are only used in other apps. To test those abstract models and mixins I created concrete models (from `django.db.models.Model`), that use these abstract models and mixins, in `test.py`. I created them in `test.py`, so that the test models don't get created in th

Re: How to view the generated SQL for test models?

`models.py`. Django always expects models in the models module. If you need a separate set of models just for tests, you'll need to set up a separate test app with any additional test models. Good luck, Michal -- You received this message because you are subscribed to the Google Groups

Re: How to view the generated SQL for test models?

At least to me it doesn't make a lot of sense to define new models in your tests, but I also don't know the particular problem you are solving. On Sat, Jan 16, 2016 at 1:27 PM, Brutus Schraiber wrote: > Wrong place to ask such things? > > This doesn't seem too

Re: How to view the generated SQL for test models?

Wrong place to ask such things? This doesn't seem too uncommon or complicated, or am I missing the point? Am Montag, 11. Januar 2016 16:06:22 UTC+1 schrieb Brutus Schraiber: > > Hi all… > > I have some models in a `test.py` file. How can I view the SQL that will > be generated for them? > >

How to view the generated SQL for test models?

Hi all… I have some models in a `test.py` file. How can I view the SQL that will be generated for them? Something like `django-admin sql` or similar but for models defined in `test.py` not in `models.py`. Regards, -brutus -- You received this message because you are subscribed to the Google

Re: Bi-directional ManyToMany with through gets broken when creating test database

filias, > > I personally didn't know one could define a reverse foreign key this way > and > I doubt this use case is covered by the test suite. I'm afraid it worked > for > Django < 1.8 by chance since it's not documented you can re-use the > implicitly created in

Re: Bi-directional ManyToMany with through gets broken when creating test database

Hi filias, I personally didn't know one could define a reverse foreign key this way and I doubt this use case is covered by the test suite. I'm afraid it worked for Django < 1.8 by chance since it's not documented you can re-use the implicitly created intermediary model as a `through` argument

Re: Bi-directional ManyToMany with through gets broken when creating test database

crashes. I have created a new project with only those 2 models and it seems to work correctly, so the problem is somehow related to our test runner (py.test) and something else which I still don't know. My models.py file looks like this: from django.db import models class Pizza(models.Model

Re: Bi-directional ManyToMany with through gets broken when creating test database

s = ManyToManyField(Pizza, > through=Pizza.available_stoppings.through, verbose_name='available pizzas') > > Everything was fine in django 1.7 but right now when running tests, > specifically when creating the test database, I get this exception: > > self = 0x7fd2

Bi-directional ManyToMany with through gets broken when creating test database

=Pizza.available_stoppings.through, verbose_name='available pizzas') Everything was fine in django 1.7 but right now when running tests, specifically when creating the test database, I get this exception: self = def execute(self, query, params=None): if params is None: > return Database.Cursor.exec

Re: Random auth_permission + content_type errors during test runs

Russel, Thank you for posting this great answer on why this error may be occurring. I was getting this error, and for the life of me (1-2 days), couldn't figure out the issue. Thank you!! -- You received this message because you are subscribed to the Google Groups "Django users" group.

Re: Random auth_permission + content_type errors during test runs

django_content_type table may be empty: >> >> >> ..EE >> >> Once the errors stop, they continue to the end of the test run. Here's >> the traceback for all of the er

Re: Test problems after upgrading to 1.8

I removed the table auth_message from my database, I tried to run it once more, and then I got a new similar message, so I removed that table too, and now it works again. I still don't understand why I suddenly got this error, but it's working again, so I'm happy :) onsdag 28. oktober 2015

Re: Test problems after upgrading to 1.8

It seems a bit difficult to debug from what you provided so far. One idea: do you have migrations for all your apps? If you could put together a minimal project that reproduces the problem that would be useful. On Wednesday, October 28, 2015 at 4:19:25 AM UTC-4, o_r wrote: > > I've recently

Test problems after upgrading to 1.8

I've recently upgraded from 1.3 to 1.8. I have a rather large testsuite, and by the end of the upgrade all the tests passed. Now I've added some new models, and made the new migration, and it seemed to work as expected, but when I try to run my tests again now, I get an error message like this:

Re: duplicated selenium test fails

to be aware that you can't rely on >> consistent database IDs in tests. > > So there is no test isolation where I assumed it to be. There is test isolation, it just doesn't extend to sequences. Tables are cleared of all data in between tests, so your second test still sees only a single Post

Re: duplicated selenium test fails

Thanks Carl! Am 21.10.2015 um 00:18 schrieb Carl Meyer: On 10/19/2015 03:03 AM, Ulrich Laube wrote: It boils down to this: [...] Is it a known problem? Not really a problem - you just need to be aware that you can't rely on consistent database IDs in tests. So there is no test isolation

Re: duplicated selenium test fails

Hi Ulrich, On 10/19/2015 03:03 AM, Ulrich Laube wrote: > It boils down to this: > > I have a selenium test in a django project against the admin page. All > green. > If I duplicate the test class via copy and paste + renaming, then one is > green and one is red, despite contai

duplicated selenium test fails

Hi! It boils down to this: I have a selenium test in a django project against the admin page. All green. If I duplicate the test class via copy and paste + renaming, then one is green and one is red, despite containing the same code. I expected both to be green. I have removed the tests from

Re: How to test authentication using REST Framework JWT?

> > It seems like this solved the issue: instead of "Authorization", I had to > include "HTTP_AUTHORIZATION" for the header key. > response = self.client.post("/auth/api/authenticated/", {}, HTTP_AUTHORIZATION='JWT {}'.format(token)) -- You received this message because you are subscribed

How to test authentication using REST Framework JWT?

JWT based authentication works well using POST requests sent from mobile and "advanced rest client", however it fails when using the Django test client. The client successfully receives the token when requested, but it gets the following response when trying to access a restr

Re: How to run all tests in INSTALLED_APPS with the new test runner 1.6?

And actually as of Django 1.8, the contrib tests aren't shipped inside each application directory, so they won't be discovered even if you switch to the old test runner. On Wednesday, October 7, 2015 at 11:21:54 AM UTC-4, jordi.gutie...@ecometrica.org wrote: > > On Wednesday, October 7

Re: How to run all tests in INSTALLED_APPS with the new test runner 1.6?

On Wednesday, October 7, 2015 at 10:16:30 AM UTC-4, Carl Meyer wrote: > > You should be aware, though, that specifically in the case of the > django.contrib app tests, we make no promise that they will pass under > your project's configuration, > That's fine. I just want to make sure *we

Re: How to run all tests in INSTALLED_APPS with the new test runner 1.6?

On 10/07/2015 06:57 AM, jordi.gutierrez.herm...@ecometrica.org wrote: > Okay, I'll try grabbing the old test runner from git, thanks. That should work fine. You should be aware, though, that specifically in the case of the django.contrib app tests, we make no promise that they will pass un

Re: How to run all tests in INSTALLED_APPS with the new test runner 1.6?

Okay, I'll try grabbing the old test runner from git, thanks. On Wednesday, October 7, 2015 at 8:38:40 AM UTC-4, Tim Graham wrote: > > Copying the old test runner from an old version of Django seems like a > fine solution. I thought someone might have published it on PyPI, but I > c

Re: How to run all tests in INSTALLED_APPS with the new test runner 1.6?

No, the new test runner does not run any 3rd party apps not in my project, and it does not run django.contrib either. On Wednesday, October 7, 2015 at 2:06:08 AM UTC-4, Gergely Polonkai wrote: > > I'm not sure I understand what you want to achieve. I use 1.8 and it runs > all tests for

Re: How to run all tests in INSTALLED_APPS with the new test runner 1.6?

Copying the old test runner from an old version of Django seems like a fine solution. I thought someone might have published it on PyPI, but I couldn't find it if so. On Wednesday, October 7, 2015 at 2:06:08 AM UTC-4, Gergely Polonkai wrote: > > I'm not sure I understand what yo

Re: How to run all tests in INSTALLED_APPS with the new test runner 1.6?

y, > I don't care too much if this is accomplished by grabbing the old > django.test.simple.DjangoTestSuiteRunner from git history or by any other > means. > > On Tuesday, October 6, 2015 at 4:24:00 PM UTC-4, Gergely Polonkai wrote: >> >> Hello, >> >> do you mean

Re: How to run all tests in INSTALLED_APPS with the new test runner 1.6?

Polonkai wrote: > > Hello, > > do you mean the integrated unittest module, or the Django test runners? > > However, both needs to be fetched from old history, and I daresay it won't > be an easy fetch. 1.6 code will more than likely be incompatible with 1.8, > so even

Re: How to run all tests in INSTALLED_APPS with the new test runner 1.6?

Hello, do you mean the integrated unittest module, or the Django test runners? However, both needs to be fetched from old history, and I daresay it won't be an easy fetch. 1.6 code will more than likely be incompatible with 1.8, so even if you backmerge it, you will have to do a lot of patching

Re: How to run all tests in INSTALLED_APPS with the new test runner 1.6?

Hey, sorry to respond to such an old thread, but now that 1.8 completely removed the old test runner, I am wondering if there's any way to get it back. I don't want to explain why I want it back. Please don't tell me I don't want it. So, starting from the axiom that I want it back, how should

Re: django.test: @override_settings(LANGUAGE_CODE = 'xx') does not affect the default language in a test

ion.get_language() == 'en' > > We are good by now. > > Then in a test, I would like to override the default language. Let's say I > have > > @override_settings(LANGUAGE_CODE='fr') > > class SomeTestCase(TestCase): > > def test_some_case(self): > self.

django.test: @override_settings(LANGUAGE_CODE = 'xx') does not affect the default language in a test

Let's say we have a default language code in settings.py LANGUAGE_CODE = 'en' Then we have >> from django.utils import translation >> assert translation.get_language() == 'en' We are good by now. Then in a test, I would like to override the default language. Let's

Re: DJango 1.8 test case fails with IntegrityError error

Hi Simon, I am working on this support . But the test case generates sql with null values for non null fields. We cannot change the model ,because this is part of python ,i believe. The problem might be the schema generated for the table from the model . I can see only one field as non null

Re: DJango 1.8 test case fails with IntegrityError error

Hi Jose, I looks like ibm_db_django doesn't support Django 1.6+ yet <https://pypi.python.org/pypi/ibm_db_django/>. Simon Le lundi 21 septembre 2015 07:14:39 UTC-4, Jose Paul a écrit : > > I am trying to run DJango 1.8 test cases with DB2 > > Several insert stateme

Re: DJango 1.8 test case fails with IntegrityError error

s\ibm_db-2.0.5.1-py2.7.egg\ibm_db_dbi.py", line 1247, in _execute_helper raise self.messages[len(self.messages) - 1] IntegrityError: Statement Execute Failed: [IBM][CLI Driver][DB2/NT] SQL0407N Assignment of a NULL value to a NOT NULL column "TBSPACEID=2, TABLEID=24, COLNO=5" is no

DJango 1.8 test case fails with IntegrityError error

I am trying to run DJango 1.8 test cases with DB2 Several insert statement fails Here is the insert command generated by test case. INSERT INTO "AUTH_USER" ("PASSWORD", "LAST_LOGIN", "IS_SUPERUSER", "USERNAME", "FIRST_NAME",

Re: 1.7 to 1.8 upgrade: test suite failing

version of test lifecycle methods is *always* run (setUpTestData, setUp etc.). Be careful with any mixins or missing super() calls that might be circumventing the TestCase version of the method (it seems like you could get away with this in 1.7 but not 1.8) 2. Avoid setUpClass, use setUpTestData

Re: is there anybody who test this django mongodb engine ?

goDB *at the types of problems that MongoDB is supposed to solve*. http://www.enterprisedb.com/postgres-plus-edb-blog/marc-linster/postgres-outperforms-mongodb-and-ushers-new-developer-reality > I was searching for 3rd party for using Mongo with django and I ends up > with django-mongodb-en

is there anybody who test this django mongodb engine ?

Hi folks I just start learning and using mongoDB , it's looks like a really nice replacement for mysql. I was searching for 3rd party for using Mongo with django and I ends up with django-mongodb-engine. Has anybody test it? I'm looking for personal experiences -- You received this message

Re: 1.7 to 1.8 upgrade: test suite failing

se try adding the super() calls. >>> >>> On Tuesday, July 14, 2015 at 5:44:09 AM UTC-4, tom.sz...@eporta.com >>> wrote: >>>> >>>> Hi, yes. Some of my test classes do use setUpClass() without calling >>>> super(). >>>> >>

Re: 1.7 to 1.8 upgrade: test suite failing

ase try adding the super() calls. >> >> On Tuesday, July 14, 2015 at 5:44:09 AM UTC-4, tom.sz...@eporta.com >> wrote: >>> >>> Hi, yes. Some of my test classes do use setUpClass() without calling >>> super(). >>> >>> On Monday,

Re: 1.7 to 1.8 upgrade: test suite failing

Unfortunately, adding the super() calls didn't help. On Tuesday, July 14, 2015 at 12:47:02 PM UTC+1, Tim Graham wrote: > > Please try adding the super() calls. > > On Tuesday, July 14, 2015 at 5:44:09 AM UTC-4, tom.sz...@eporta.com wrote: >> >> Hi, yes. Some of my test c

Re: 1.7 to 1.8 upgrade: test suite failing

Please try adding the super() calls. On Tuesday, July 14, 2015 at 5:44:09 AM UTC-4, tom.sz...@eporta.com wrote: > > Hi, yes. Some of my test classes do use setUpClass() without calling > super(). > > On Monday, July 13, 2015 at 5:44:03 PM UTC+1, Tim Graham wrote: >> >&g

Re: 1.7 to 1.8 upgrade: test suite failing

Hi, yes. Some of my test classes do use setUpClass() without calling super(). On Monday, July 13, 2015 at 5:44:03 PM UTC+1, Tim Graham wrote: > > Do your test classes use setUpClass() and/or tearDownClass()? If so, are > you missing super() calls in those methods? > > On Monday

Re: 1.7 to 1.8 upgrade: test suite failing

Do your test classes use setUpClass() and/or tearDownClass()? If so, are you missing super() calls in those methods? On Monday, July 13, 2015 at 9:37:03 AM UTC-4, tom.sz...@eporta.com wrote: > > Thanks for the link > This is the commit at which my tests start failing: > da9fe5c

Re: 1.7 to 1.8 upgrade: test suite failing

re's what I meant by "bisecting the commit": > > > https://docs.djangoproject.com/en/dev/internals/contributing/triaging-tickets/#bisecting-a-regression > > On Monday, July 13, 2015 at 5:50:49 AM UTC-4, tom.sz...@eporta.com wrote: >> >> Thanks for the swift reply.

<    1   2   3   4   5   6   7   8   9   10   >