Changes between Version 2 and Version 3 of SummerOfCode2011

Timestamp:

Feb 10, 2011, 7:13:22 AM (14 years ago)

Author:

Russell Keith-Magee

Comment:

Removed testing project; added best practices refactor

SummerOfCode2011

@@ -191 +191 @@
  * #7735
 
-=== Testing updates ===
- * '''Complexity:''' Minor
-
-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.
-
-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.
-
-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.
-
-Issues to consider:
- * 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?
- * Is there any part of this process that can be automated? If so, How?
- * Will migrating from doctests to unittests cause any performance problems? Are there any ways to limit these performance problems?
-
-See also:
- * [source:django/trunk/tests Django's test suite]
- * [source:django/trunk/django/test Django's testing utilities]
- * [http://docs.djangoproject.com/en/dev/topics/testing Documentation on Django's testing utilities]
+=== Best practices updates ===
+* '''Complexity:''' Moderate
+
+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.
+
+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).
+
+In 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.
+
+Issues to consider:
+ * What components need to be updated, and why?
+ * How to do this update while maintaining backwards compatibility?
+
+See also:
+ * # 8579