Re: Django testing strategy
There are a couple of problems with setting up a big database and then writing integration tests. Your tests will be slow, so they won't get run. They'll also be increasingly hard to maintain. Fixtures only seem make that worse. You've already got a code base that needs maintaining, you don't want to add another one. BUT you also have the problem that writing nice, isolated unit tests is going to require a lot of refactoring. That's scary because you don't have any tests in place, so you might break something and not know about it. I would approach it like this: 1) Decide on one functional area or workflow that you want to start with. Preferably, this would be (relatively) self-contained. 2) Create the fixtures you need for testing that area. 3) Write some high-level integration tests that cover all the important workflows for your user. I'd use the built in test client or WebTest for this. 4) Start writing real unit tests for the code in this area. Where necessary use factory_boy to set up your models, rather than fixtures. Mock your external dependencies. You will almost certainly have to do a lot of refactoring in order to write good, isolated unit tests. But you now have some confidence that you're not breaking things because of the high level integration tests. 5) Once you've achieved some good coverage with your unit tests, either start on a new area or refactor your integration tests. Get rid of the fixtures and move to factory_boy. Make sure you're testing the minimum necessary at this level, because they'll be your slowest and most fragile tests. There's an excellent presentation by Carl Meyer that covers some tools and approaches to write better tests: http://pycon-2012-notes.readthedocs.org/en/latest/testing_and_django.html Hope that helps. Josh On Friday, 5 October 2012 01:49:19 UTC+8, Daniele Procida wrote: > > I have started writing my first tests, for a project that has become > pretty large (several thousand lines of source code). > > What needs the most testing - where most of the bugs or incorrect appear > emerge - are the very complex interactions between objects in the system. > > To me, the intuitive way of testing would be this: > > * to set up all the objects, in effect creating a complete working > database > * run all the tests on this database > > That's pretty much the way I test things without automated tests: is the > output of the system, running a huge database of objects, correct? > > However, I keep reading that I should isolate all my tests. So I have had > a go at creating tests that do that, but it can mean setting up a dozen > objects sometimes for a single tiny test, then doing exactly the same thing > with one small difference for another test. > > Often I have to run save() on these objects, because otherwise tests that > depend on many-to-many and other database relations won't work. > > That seems very inefficient, to create a succession of complex and > nearly-identical test conditions for dozens if not hundreds of tests. > > I'd appreciate any advice. > > Daniele > > -- You received this message because you are subscribed to the Google Groups "Django users" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/Tz7_T4pZfTgJ. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: django in docker
Rather than making everything world-readable, I usually create a user and chown all the directories to that user. Can you post your Dockerfile? On Wed, Jul 6, 2016 at 5:28 AM, Larry Martell wrote: > I am trying to run nginx/uwsgi/django in a docker container. If I > mount the dir with my django project in the container when I create > the container it works fine. But I want to make the image > self-contained and not dependent on the local file system. So I > changed the Dockerfile to copy the dir containing the django project > from the host machine into the image. But then, when I create the > container (without mounting the dir) I get permission denied on all > accesses to that dir (e.g. the socket, the static files, ...). > Everything is world readable and executable. Anyone have any clues as > to what could be causing this? > > -- > 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 django-users@googlegroups.com. > Visit this group at https://groups.google.com/group/django-users. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-users/CACwCsY7Pz7mtEBR%3DKNfwC9AX8WtcvJAutAH-ZMkG9HBYS04Ksw%40mail.gmail.com. > For more options, visit https://groups.google.com/d/optout. -- 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 django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAKoVLMjyCrnhe24iioOehweC725NomjffUNnXaJNonV5AA62gw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Testing a Django library
There's no Django community standard of which I'm aware for doing this. There *is* a standard way to run tests for Python projects which use setuptools (which yours should do if you want people to be able to `pip install` it) [1]. I usually do something like this blog post describes [2]. Or, you could use this cookie cutter template [3] if you don't want to set it up manually yourself. It's probably the closest thing you'll find to a "standard". [1] http://peak.telecommunity.com/DevCenter/setuptools#test [2] http://joebergantine.com/blog/2015/dec/03/test-reusable-django-application-support-multiple-/ [3] https://github.com/pydanny/cookiecutter-djangopackage On Tuesday, 21 March 2017 09:38:41 UTC+11, th...@copperleaf.com wrote: > > I am working on a Django library (which will be packaged) and want to set > up testing for it. Looking at a number of existing Django libraries, here > seem to be a number of ways to set up testing, and all of them are > different. > > Are there any best practices? Is there a guide that specifies how it > should be done? > > T > > -- 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 django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/e32424cb-8b12-455e-8f16-f73a850d7c26%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
