Changes between Version 1 and Version 2 of SummerOfCode2015


Ignore:
Timestamp:
Jan 27, 2015, 2:10:43 PM (10 years ago)
Author:
Marc Tamlyn
Comment:

Tidy up/expand ideas, add self as possible mentor for testing improvements.

Legend:

Unmodified
Added
Removed
Modified
  • SummerOfCode2015

    v1 v2  
    1111
    1212 * Tim Graham (timograham@gmail.com) - Replace Form Media
     13* Marc Tamlyn (marc.tamlyn@gmail.com) - Test framework cleanup
    1314
    1415== Students ==
     
    7677* '''Complexity:''' Moderate
    7778
    78 Over the years, as Django has evolved, the idea of what constitutes "best practice" has also evolved. However, some parts of Django haven't kept up with those best practices. For example, contrib.comments and contrib.databrowse aren't deployable apps in the same sense as contrib.admin. As a result, these apps can't be (easily) deployed multiple times, and they can't use URL namespacing.
    79 
    80 In addition, some features of Django's core have grown and evolved, and need refactoring. For example, validation is now performed in several places, but don't operate by hooking into the core 'validate' command. In addition, many aspects of the core validate command should be farmed out to the things that are being validated (e.g., the max/min conditions on a field should be validated by the field, not by a third party validator).
     79Over the years, as Django has evolved, the idea of what constitutes "best practice" has also evolved. However, some parts of Django haven't kept up with those best practices. For example, contrib apps do not use class based views.
    8180
    8281In short, Django has been bad at eating it's own dogfood. The contents of contrib should be audited and updated to make sure it meets current best practices.
     
    9493Django has an extensive test framework for Python code, a suite of tools to make server-side testing easier, and a project policy that no new code is added without tests. This has been a significant contributor to the stability of Django as a project.
    9594
    96 For the 1.4 release, we also included the basis of a client-side testing framework into Django (https://docs.djangoproject.com/en/dev/topics/testing/#django.test.LiveServerTestCase)
     95However, this now means that Django has a very large and powerful test suite without much separation or control from a user's perspective, so the goal of this project would be to add new options and suite types to allow running of specific types of tests, be they only a certain class (e.g. unit-tests only, selenium tests only) or excluding tests (such as the ones in contrib or third-party apps) from the main test run easily.
    9796
    98 However, this now means that Django has a very large and powerful test suite without much separation or control from a user's perspective, so the goal of this project would be to add new options and suite types to allow running of specific types of tests, be they only a certain class (e.g. unit-tests only, selenium tests only) or excluding tests (such as the ones in contrib or third-party apps) from the main test run easily.
     97Django's test suite is also very large with over 1000 models. In some areas, the tests are poorly structured and it is not clear where similar related tests should be placed. It is likely there may be some duplication of features tested, and there are certainly edge cases which are not tested. For example, standardising all the unit tests necessary for a particular model field type would be beneficial.
    9998
    10099Issues to consider:
     
    103102 * How will it be app maintainers run their tests?
    104103 * Should there be additional hooks to, for example, allow tests to be run against different database backends in sequence?
     104 * Are there tools similar to the new `--debug-sql` option which would help developers working on Django?
    105105
    106106See also:
     
    127127
    128128If you are interested in working on this project, please talk to us sooner rather than later! PaulM is usually available on IRC, and wants to help you write a really good application.
    129 
    130 === Improve annotation and aggregation ===
    131  * '''Complexity:''' Medium
    132 
    133 The 2009 Summer of Code added the annotate() and aggregate() calls to Django's query arsenal. While these tools work well for simple arithmetic aggregates, they don't work well for date and string based queries. There are also use cases where you may want to annotate data onto a model that *isn't* an aggregate (for example, annotating the sum of two other aggregates).
    134 
    135 This project would continue where the 2009 GSoC aggregation project left off. This would be an excellent project for anyone wishing to gain an intimate understanding of Django's Query infrastructure.
    136 
    137 Issues to consider:
    138  * String concatenation and manipulation (e.g., annotate a model with the uppercase version of the first 5 characters of someone's name)
    139  * Grouping of results by date (e.g., show me a count of articles, grouped by day)
    140  * Allowing non-null defaults in aggregation (e.g., when a model has no related objects, use 0 not NULL)
    141  * Aggregates involving generic relations
    142 
    143 See also:
    144  * [https://code.djangoproject.com/query?status=assigned&status=new&keywords=~annotate&keywords=~aggregate&component=Database+layer+%28models%2C+ORM%29&col=id&col=summary&col=status&col=owner&col=type&col=version&order=priority Trac's list of ORM aggregation tickets]
    145  * The [source:django/trunk/django/db/query.py Django's QuerySet implementation]
    146129
    147130=== Reducing coupling in Django components ===
     
    176159 * [https://code.djangoproject.com/query?status=assigned&status=new&summary=~oracle&or&status=assigned&status=new&keywords=~oracle&col=id&col=summary&col=status&col=owner&col=type&col=component&order=priority Trac's list of Oracle issues]
    177160 * Similar queries for 3rd-party backends should be added here
     161
     162=== Replacing middleware ===
     163* "Complexity:" Hard
     164
     165Django's middleware infrastructure is not particularly good. In particular the handling of exceptions is not necessarily predictable.
     166
     167It also has no way of applying itself to anything other than the entire site. With the advent of class based views, decorators are not particularly clean, and are also easily omitted. For example consider an entire reporting section which requires certain permissions - applying the permission requirement at the URLconf level reduces the chance of missing single views and leaving security vulnerabilities.
     168
     169A related area is providing alternatives to the regular expression based url resolvers.
Back to Top