I've written an application to improve Django's Test Suite. http://code.djangoproject.com/wiki/SummerOfCode2010#Testingupdates
My application is here (also pasted below for convenience): http://socghop.appspot.com/gsoc/student_proposal/show/google/gsoc2010/paulmcmillan/t127077396156 I'm hoping for constructive feedback particularly in the area of maintaining test integrity. I realize this is a fairly late application, but the task itself is relatively non-controversial. Thanks! -Paul ========================= The problem Django's testing suite has become fragmented over time. The modeltests and regressiontests directories serve similar purposes and should be joined. Nobody wants to do concerted work to improve testing because it isn't a showstopping bug or a new feature. GSOC provides an opportunity to support this kind of work. Proposal I will merge the code in modeltests and regressiontests, turning doctests into unit tests and cleaning up existing code as I go. I will use coverage.py to verify that the re-written tests cover the same areas of code as the previous ones did, as well as identifying areas without coverage. Many GSOC proposals are for large feature improvements that will involve a major code branch and merge. This project can instead be done as a series of incremental patches, reducing the impact of a failure to complete and providing more immediate results. In order to avoid introducing new bugs, I will configure a variety of virtual machines for testing. At a minimum, I will test in Ubuntu, Windows XP, and Mac OS X, with the most recent versions of Python 2.4, 2.5, and 2.6. On each of these systems, I will test against the supported database backends (PostgreSQL, MySQL, SQLite, Oracle). I will build scripts to automate the test running in these environments so that testing can continue prior to patches being merged to trunk. Since Django 1.2 is dropping support for Python 2.3, there is extra code in the test suite to support 2.3 that can be removed. This should improve the speed of test running. Internally, when a doctest is run, Python converts it into a unittest before actually executing it. It might be possible to use this code to automate the conversion. Converting to unittests should improve test run time because it eliminates the parsing necessary to convert each doctest into a unittest. The #python IRC channel anecdotally agrees on this point. Timeline Week 1: Configure test systems, build infrastructure to automate testing on these systems. Investigate code to automate conversion from doctests to unittests. Get coverage.py working and establish a baseline for what is covered. Week 2-10: There are 136 directories in modeltests and regressiontests. I will convert and clean up 15 directories per week. Some weeks will be harder than others, and I will spread out the especially labor intensive directories. Week 10-12: This is an overflow buffer if anything turns out to be unexpectedly time consuming. If it is not necessary, I can revert to more general code cleanup or bugfix tasks, particularly those related to performance profiling. I expect to devote 20-30 hours per week to the project. Some weeks I may have to devote more time if a particular set of tests are hard to convert. About you I'm a student at UC Berkeley entering my final undergraduate year in the Cognitive Science program. I successfully completed the 2008 Summer of Code for NESCENT, and currently work on a number of Django- powered projects for clients of my company. I contribute to StackOverflow, and enjoy photography. My Resume: http://careers.stackoverflow.com/paulmcmillan -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
