Re: Simplest unit testing of models fail ...
On Sun, Oct 19, 2008 at 5:06 PM, zobbo <[EMAIL PROTECTED]> wrote: > > When a test fails and another test then runs, it dies because the > transaction is in error. The field with too many chars fails and that > causes the next test to raise an error. If you switch the backend to > SQLLite for example you don't get any errors. > > Funnily enough, I can stop that happening by using the solution given > at:: > > http://www.stereoplex.com/two-voices/django-unit-tests-and-transactions > > Although the comments to that article imply that Django's own unit > test framework should be doing this? I'm not sure what those comments are referring to, but Django's test framework doesn't currently do anything with transactions. This is mostly because MySQL and SQLite don't support nested transactions, so if Django's test framework used transactions, none of the code being tested would also be able to use transactions. There is a ticket (#8138) that modifies the Django test framework to use transactions, but that change is directed at improving the time required to run tests, not making tests resilient to in-test errors. This is because rolling back a database is a much faster operation than flushing and recreating. The setup/teardown approach suggested by the blog post you reference isn't appropriate for the generic case, but you should certainly consider it for your own projects. If you aren't using transactions in your own code, or you're using a database that supports nested transactions, that approach will certainly work. Yours, Russ Magee %-) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Simplest unit testing of models fail ...
On Sun, Oct 19, 2008 at 8:38 AM, zobbo <[EMAIL PROTECTED]> wrote: > > After some conversation on irc, it appears that you can only validate > Django objects by using Django forms. > > I do find that odd but I won't get into that conversation at the > moment. > > Instead let me describe my problem to the world and see if anybody has > any suggestions. > > [snip] > Am I barking up the wrong tree completely? > No. Model validation is being developed, it's just not there yet. The ticket to watch in #6845: http://code.djangoproject.com/ticket/6845 It's got a recent patch if you're feeling adventurous and want to help out with getting it tested and integrated into the code base. If not, here's a blog post from Malcolm about an approach to using forms to do your own model validation now: http://www.pointy-stick.com/blog/2008/10/15/django-tip-poor-mans-model-validation/ Karen --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Simplest unit testing of models fail ...
After some conversation on irc, it appears that you can only validate Django objects by using Django forms. I do find that odd but I won't get into that conversation at the moment. Instead let me describe my problem to the world and see if anybody has any suggestions. I have a number of applications which are 50% web frontend and 50% python backend. Historically the frontends have been either zope or Ruby on Rails. Historically the two sides have communicated using xmlrpc. That's fine for small pieces of data but we doesn't scale particularly well. I'll outline one issue. We have, in the python backend, logic for scanning. Users have scanners. When all 20 parts on a stillage are scanned, that stillage is closed. When all four stillages on a stillage cycle are scanned, that stillage cycle is closed. There are special rules for allowing rescanning etc and that all sits within the python/twisted code. If the scanners go down we have to use frontends to do the same thing. So now they're clicking on parts and completing stillages. etc. etc. It's the same rules but this time they're inputting through the web frontend, not over scanners going into a ip socket. I want that logic in ONE place. My plan was to use the Django ORM to handle this but now I have to cope with the fact that (for example) although Django has been told the input can't be more than 5 chars for a certain input, it will only use that logic if I am using the models with the Django frontend. So on the backend I've got to sanitise the data before tyring to write it and that's just duplication. Why am I using Django? Because 90% of the web stuff is provided by the admin site in Django and it does a damn fine job. But should I consider moving elsewhere? Am I barking up the wrong tree completely? Ian --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Simplest unit testing of models fail ...
Russell Many thanks for taking the time to reply. On Oct 19, 6:13 am, "Russell Keith-Magee" <[EMAIL PROTECTED]> wrote: > On Sun, Oct 19, 2008 at 4:00 AM, Ian J Cottee <[EMAIL PROTECTED]> wrote: > As far as I can make out, the error you are getting is unrelated to > the problem you are describing. Your error is telling you that you > can't flush the database. If you're getting that error, Django hasn't > started to run the test yet, so the issue isn't with your test code. > If your test case contained nothing but "self.assertEquals(1,1)", you > would get the same error. The problem lies with the test database > itself. I did as you said. The issue is actually one that I now recall I reported last January http://tinyurl.com/5r6jm6 When a test fails and another test then runs, it dies because the transaction is in error. The field with too many chars fails and that causes the next test to raise an error. If you switch the backend to SQLLite for example you don't get any errors. Funnily enough, I can stop that happening by using the solution given at:: http://www.stereoplex.com/two-voices/django-unit-tests-and-transactions Although the comments to that article imply that Django's own unit test framework should be doing this? I think I have two questions now: 1. Is this a bug? Surely one test failing shouldn't affect the other tests? And surely running your unit tests against different backends should give the same result. and perhaps much more simply ... 2. How DO you test if an object is going to fail to be saved, before trying to save it? The validates method appears to have been removed now. For the record this is Django from svn using postgres 8.3 and psycopg2, running on Hardy, Ian --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Simplest unit testing of models fail ...
On Sun, Oct 19, 2008 at 4:00 AM, Ian J Cottee <[EMAIL PROTECTED]> wrote: > > Given a backend of postgres and a simple test to test that, for > example, your model does not accept fields with more characters than > it should ... how do you do it? > > I have a part database which has two fields - code and description. e.g. > >class Part(models.Model): >code = models.CharField(max_length=15) >description = models.CharField(max_length=50) > > I want to make sure that a code field can't have more than 15 chars. > Even if I just greedily swallow the exception:: > >def testPartCodeBad(self): >"""Reject our bad code""" >part = Part() >part.code = '1234567890123456' >part.description = 'AA' > >try: >part.save() >except: >pass > > I still end up with > >Destroying old test database... >Creating test database... >Creating table auth_permission >Creating table auth_group >Creating table auth_user >Creating table auth_message >Creating table django_content_type >Creating table django_session >Creating table django_site >Creating table django_admin_log >Creating table stock_part >Installing index for auth.Permission model >Installing index for auth.Message model >Installing index for admin.LogEntry model >.Error: Database test_taiko couldn't be flushed. Possible reasons: > * The database isn't running or isn't configured correctly. > * At least one of the expected database tables doesn't exist. > * The SQL was invalid. >Hint: Look at the output of 'django-admin.py sqlflush'. That's > the SQL this command wasn't able to run. >The full error: current transaction is aborted, commands > ignored until end of transaction block > > What it actually means is, you stuck 16 chars where only 15 chars were > allowed. > > Is this testable? As far as I can make out, the error you are getting is unrelated to the problem you are describing. Your error is telling you that you can't flush the database. If you're getting that error, Django hasn't started to run the test yet, so the issue isn't with your test code. If your test case contained nothing but "self.assertEquals(1,1)", you would get the same error. The problem lies with the test database itself. It's difficult to say exactly what the problem is without seeing your database setup. However, the error that is being raised is caused by the fact that Django can't flush the test database. The most likely cause I can think of is a permissions problem - your test user doesn't have permission to run DELETE TABLE on the test database. To debug this problem, follow the instructions you have been given in the error message: run ./manage.py sqlflush, and try to execute that SQL manually on using the test database. This should reveal the underlying problem. Yours, Russ Magee %-) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
