Changes between Version 2 and Version 3 of SummerOfCode2011

02/10/11 07:13:22 (5 years ago)

Removed testing project; added best practices refactor


  • SummerOfCode2011

    v2 v3  
    191191 * #7735
    193 === Testing updates ===
    194  * '''Complexity:''' Minor
    196 Django's test suite originally consisted almost entirely of doctests; these doctests were used as a supplement to the written documentation. Over time, this supplemental role has been dropped. The doctests have also gotten larger;  in some cases (such as the queries regressiontest) they are now extremely unwieldly. New tests that are added to Django tend to be UnitTests when possible, but the existing legacy of doctests is hard to break in some cases.
    198 There is also an artificial distinction between modeltests and regressiontests. In the past, this distiction was used to identify tests that served a documentation purpose; this role has long since disappeared, but the struture persists, leading to confusion over the 'right place' to test certain features represented in both directories.
    200 These two tasks indicate a need to refactor Django's test suite. The aim of this project would be to update Django's test framework; migrating as doctests to UnitTests, and merging the modeltests and regressiontests directories.
    202 Issues to consider:
    203  * How to maintain the integrity of Django's test suite? Django has spent a lot of effort building a strong regression test suite; how do we ensure that by refactoring the test suite, we don't lose the integrity of that regression set?
    204  * Is there any part of this process that can be automated? If so, How?
    205  * Will migrating from doctests to unittests cause any performance problems? Are there any ways to limit these performance problems?
    207 See also:
    208  * [source:django/trunk/tests Django's test suite]
    209  * [source:django/trunk/django/test Django's testing utilities]
    210  * [ Documentation on Django's testing utilities]
     193=== Best practices updates ===
     194* '''Complexity:''' Moderate
     196Over 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.
     198In 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).
     200In 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.
     202Issues to consider:
     203 * What components need to be updated, and why?
     204 * How to do this update while maintaining backwards compatibility?
     206See also:
     207 * # 8579
Back to Top