Upgrade the Awesomness Quotient of the Django Test Utils and Regression Suite

Abstract

To fix and test, so cover the Admin site/ with Windmill use, avoiding the great fright. At moment be, we cover not, popular/ is the admin but tested is not. Great addition tests would be/ the key in promoting greater Django harmony.

The Problem

Django has a fantastic set of regression tests which cover much of the codebase, but the famous Admin interface isn't covered by any sort of automated tests. In addition, the tools for testing a site under the Django framework are weak, even if the API's available are quite powerful.

Proposal

Overall Django has some great testing tools, but the addition of a few key integrations and tools could make it a much more comprehensive and easy to use testsuite. Namely, nose runners and extensions, Windmill integration, and some expansions to the core testing API's. Namely, I want to accomplish the following:

  1. Windmill support already works/exists! Add anything that might be missing.

  2. Expand the Django test runner to provide Code Coverage statistics. There are already some efforts towards this goal underway, and I don't plan on reinventing the wheel. My hope is to integrate their work, and potentially expand it based on Django's community requests. Most likely the base of this work will be figleaf, but I plan on researching other options. Lastly, I want to evaluate the coverage of Django's current regression suite and provide a wiki page/writeup detailing any major deficiencies so that they can be addressed. (Similar to this ticket: CodeCoverage)

  3. Utilize the new Windmill test support to provide coverage of the Admin interface. This is an extremely large task overall, but given how easy Windmill has made the creation of tests, I hope that I will be able to provide coverage of a majority of the admin's functionality. This will not include support for the django.contrib.gis namespace, but I will try and test all other namespaces that have Admin integration or functionality (namely auth, admin and comments).

  4. New Cleanup/Expand the current testing API to include a few new super-awesome features/functions. Namely, I want to implement/integrate the following tickets (listed in order of priority):
    1. Skipping Tests
    2. assertNumQueries
    3. assertContext
    4. assertNoBrokenLinks
    5. Mock Request Creation Outside of urls
    6. Fixtures with doctests
    7. TestOnly Models
    8. reStructured Text Checker
    9. fuzz or datagen testing

Timeline

Weekly I should be able to put in between 20-30 hours a week, but that will be focused on the weekends. During the week I will have classes, but will be available during many of them for discussion, but will avoid coding. (I have 2 lab classes that require me to be in a room for 4 hours, but most of the time is watching something settle or spin or do nothing at all). A breakdown of my projected timing:

  • Week 1: Gain familiarity with Windmills capabilities and limitations, scope of each addition and research into other implementations.
  • Week 2: Get code coverage working for both Django Regression Suite and under a manage command.
  • Week 3-7: This is the time for as much of item 4 as is feasible. Absolute no-doubt is to get a-e implemented. f might not have a clever solution, h is easy to implement and hard to test completely (for not that much benefit in my mind), i just isn't that important, and j is very nebulous, and generally not all that helpful.
  • Week 8-10: Write first Windmill test for admin. Determine the 'environment' or set of Models we will use to test the Admin. The goal here is not to have the entire admin interface covered, it is to encapsulate ChangeList (possibly with actions, def with filter/drilldown/search) and basic object adding/deleting (including all Field types, but probably not Inline edits). Then its just some Test mania! Windmill test writing fury. My plan is to develop a best-practice for Windmill tests, as well as a strong repository of examples.
  • Week 10-12: Discuss missing tests or other cases to check. Possibly provide branch of tests for new admin work (if that project is accepted for GSOC). Implement any of item 4[a:f] that didn't get implemented, as well as inline edits in the admin tests (if I'm on/ahead of schedule).

About you

I'm a long-time open source junkie in my last few quarters at Neumont University. I've been writing Python the past 2 years or so, and have been a Django user for the past year.