On 7 févr. 2015, at 01:02, Russell Keith-Magee <russ...@keith-magee.com> wrote:
> I've thought about (but never done anything) about this problem in the past - > my thought for this problem was to use multiple test databases, so you have > isolation. Yes this means you need to do more manual setup (createdb > test_database_1; createdb test_database_2; etc), but it means you don't have > any collision problems multiprocessing an on-disk database. The fastest way to do this is probably to create a database then clone it. Each backend would have to implement a duplication method: - SQLite: os.copy(‘django_test.sqlite3’, ‘django_test_N.sqlite3’) - PostgreSQL: CREATE DATABASE django_test_N WITH TEMPLATE django_test OWNER django_test; - MySQL: mysqldump … | mysql … - Oracle: apparently there’s a DUPLICATE command — I have a bad feeling about this one. For optimal speed, this feature should support --keepdb. > My only "concern" relates to end-of-test reporting - how are you reporting > test success/failure? Do you get a single coherent test report at the end? Do > you get progress reporting, or just "subprocess 1 has completed; 5 failures, > 200 passes" at the end of a subprocess? My interest here isn't strictly about > Django - it's about tooling, and integration of a parallelized test suite > with IDEs, or tools like Cricket. Yes, I have a clean report. If you look at the pull request you’ll see two successive implementations: 1) Run tests in workers, pass “events" back to the master process, feed them to the master test runner. Unfortunately this technique is never going to be sufficiently robust because it involves passing tracebacks between processes and tracebacks aren’t pickleable in general. 2) Run tests in worker, buffer the output in workers, have the master test runner reconstruct proper output. This is less elegant. It only works with the TextTestRunner because it depends heavily on its internals. But it’s more robust and it suffices for running Django’s test suite. What this really means is — you have to choose between being a proper unittest2 runner or being robust. That’s what I meant when I said the unittest2 APIs made the implementation painful. -- Aymeric. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/6732B9C6-3172-4D07-9354-1DDD21AF4100%40polytechnique.org. For more options, visit https://groups.google.com/d/optout.
