Package: django-concurrent-test-helper
Helpers for executing Django app code concurrently within Django tests.Tested against the same versions of Python thatDjango supports:xPy2.7Py3.4Py3.5Py3.6Django 1.4Django 1.5Django 1.6Django 1.7Django 1.8Django 1.9Django 1.10Django 1.11(with the exception of Python 3.2 and 3.3… these are no longer supported)Getting startedpipinstalldjango-concurrent-test-helperGoes well withhttps://github.com/box/flaky(pip install flaky), as you may want to run a test several times while trying to trigger a rare race condition.You may need to set a config value in your Djangosettings.py. By default we useMANAGE_PY_PATH ="./manage.py", this should work for most cases. If you need another path setMANAGE_PY_PATHin your Django settings.You need to add this library to your Django project settings too:INSTALLED_APPS=(# ...'django_concurrent_tests',)Two helpers are provided:fromdjango_concurrent_tests.helpersimportcall_concurrentlydefis_success(result):returnresultisTrueandnotisinstance(result,Exception)deftest_concurrent_code():results=call_concurrently(5,racey_function,first_arg=1)# results contains the return value from each callsuccesses=list(filter(is_success,results))assertlen(successes)==1and:fromdjango_concurrent_tests.helpersimportmake_concurrent_callsdefis_success(result):returnresultisTrueandnotisinstance(result,Exception)deftest_concurrent_code():calls=[(first_func,{'first_arg':1}),(second_func,{'other_arg':'wtf'}),]*3results=make_concurrent_calls(*calls)# results contains the return value from each callsuccesses=list(filter(is_success,results))assertlen(successes)==1Note that if your called function raises an exception, the exception will be wrapped in aWrappedErrorexception. This provides a way to access the original traceback, or even re-raise the original exception.importtypesfromdjango_concurrent_tests.errorsimportWrappedErrorfromdjango_concurrent_tests.helpersimportmake_concurrent_callsdeftest_concurrent_code():calls=[(first_func,{'first_arg':1}),(raises_error,{'other_arg':'wtf'}),]*3results=make_concurrent_calls(*calls)# results contains the return value from each callerrors=list(filter(lambdar:isinstance(r,Exception),results))assertlen(errors)==3assertisinstance(errors[0],WrappedError)assertisinstance(errors[0].error,ValueError)# the original errorassertisinstance(errors[0].traceback,types.TracebackType)# other things you can do with the WrappedError:# 1. print the tracebackerrors[0].print_tb()# 2. drop into a debugger (ipdb if installed, else pdb)errors[0].debug()ipdb># ...can explore the stack of original exception!# 3. re-raise the original exceptiontry:errors[0].reraise()exceptValueErrorase:# `e` will be the original error with original tracebackAnother thing to remember is if you are using theoverride_settingsdecorator in your test. You need to also decorate your called functions (since the subprocesses won’t see the overridden settings from your main test process):fromdjango_concurrent_tests.helpersimportmake_concurrent_calls@override_settings(SPECIAL_SETTING=False)deftest_concurrent_code():calls=[(first_func,{'first_arg':1}),(raises_error,{'other_arg':'wtf'}),]*3results=make_concurrent_calls(*calls)@override_settings(SPECIAL_SETTING=False)deffirst_func(first_arg):returnfirst_arg*2defraises_error(other_arg):# can also be used as a context managerwithoverride_settings(SPECIAL_SETTING=False):raiseSomeError(other_arg)On the other hand, customised environment varswillbe inherited by the subprocess and anoverride_environmentcontext manager is provided for use in your tests:fromdjango_concurrent_tests.helpersimportcall_concurrentlyfromdjango_concurrent_tests.utilsimportoverride_environmentdeffunc_to_test(first_arg):importosreturnos.getenv('SPECIAL_ENV')deftest_concurrent_code():withoverride_environment(SPECIAL_ENV='so special'):results=call_concurrently(1,func_to_test)assertresults[0]=='so special'Lastly, you can pass a string import path to a function rather than the function itself. The format is:'dotted module.path.to:function'(NOTE colon separates the name to import, after the dotted module path).This can be nice when you don’t want to import the function itself in your test to pass it. But more importantly it isessentialin some cases, such as whenfis a decorated function whose decorator returns a new object (andfunctools.wrapswas not used). In that situation we will not be able to introspect the import path from the function object’s__module__(which will point to the decorator’s module instead), so for those cases calling by string ismandatory. (Celery tasks decorated with@app.taskare an example which need to be called by string path)fromdjango_concurrent_tests.helpersimportcall_concurrently@bad_decoratordefmyfunc():returnTruedeftest_concurrent_code():results=call_concurrently('mymodule.module:myfunc',3)# results contains the return value from each callresults=list(filter(None,results))assertlen(results)==3NOTESWhy subprocesses?We originally wanted to implement this purely usingmultiprocessing.Poolto call the function you want to test. If that had worked then this module would hardly be necessary.Unfortunately we hit a problem with this approach: multiprocessing works by forking the parent process. The forked processes inherit the parent’s sockets, so in a Django project this will include things like the socket opened by psycopg2 to your Postgres database. However the inherited sockets are in a broken state. There’s a bunch of questions about this on SO and no solutions presented, it seems basically you can’t fork a Django process and do anything with the db afterwards.(Note in Python 3 you may be able to use the‘spawn’ start methodof multiprocessing to avoid the fork problems - have not tried this)So in order to make this work we have to usesubprocess.Popento run with un-forked ‘virgin’ processes. To be able to test an arbitrary function in this way we do an ugly/clever hack and provide amanage.py concurrent_call_wrappercommand (which is why you have to add this module to yourINSTALLED_APPS) which handles the serialization of kwargs and return values.This does mean that your kwargs and return valuemust be pickleable.Another potential gotcha is if you are using SQLite db when running your tests. By default Django will use:memory:for the test-db in this case. But that means the concurrent processes would each have their own in-memory db and wouldn’t be able to see data created by the parent test run.For these tests to work you need to be sure to setTEST_NAMEfor the SQLite db to areal filenamein yourDATABASESsettings (in Django 1.9 this is a dict, i.e.{'TEST': {'NAME':'test.db'}}).Finally you need to be careful with Django’s implicit transactions, otherwise data you create in the parent test has not yet been committed and is therefore not visible to the subprocesses.Ensure that you use Django’sTransactionTestCaseor a derivative (to prevent all the code in your test from being inside an uncommitted transaction).