On Sun, Dec 6, 2009 at 2:57 AM, Tobias McNulty <tob...@caktusgroup.com> wrote: > On Sat, Dec 5, 2009 at 8:40 AM, Russell Keith-Magee > <freakboy3...@gmail.com> wrote: >> * Why have all the tests migrated to the Django system tests? This is >> a contrib app - the tests should be internal to the app. > > They were moved to facilitate inclusion of a more complete test suite > with a test urls.py and views.py that make sure all the plumbing works > together. In short, I wanted a way to make use of the test Client > without including the dummy code in the distribution.
That doesn't require deployment into the system tests. Witness the contrib.auth tests; they define both views and urls that are only used during the testing process. > I think it has also been discussed elsewhere; that some would prefer > not to deploy the tests with the production application - one more > reason to keep them in 'tests' instead of in the contrib app. I disagree with this approach. If you're deploying code, you should be deploying anything that can help you validate that the code you're deploying actually works as intended. There is a bigger argument here about application and integration testing, which has been raised previously [1]. [1] http://groups.google.com/group/django-developers/msg/dba95d9702b8b5cd > From what I can tell, this seems to be in line with what some of the > other contrib apps are doing, such as admin and comments. admin and comments are bad examples here. They're in the system tests for a different reason - they require test models. i.e., you can't display an admin interface unless you have models to display. Django's app-level testing facilities don't provide for test models (yet - see #7835), so the admin and comments tests need to be in the system test area. >> * I don't know why I didn't pick this up earlier, but the emerging >> convention for pluggable backends is for the user to specify the name >> of the module, and for the module to have a predictable class name. >> i.e - each storage backend module should have a "StorageEngine" class, >> and the user specifies the name of the module. There is also an >> emerging convention to call the pluggable bits 'backends', rather than >> picking a name like 'storage'. Net result: the user should be >> configuring MESSAGE_BACKEND="django.contrib.messages.backends.user_messages" >> rather than >> MESSAGE_STORAGE = >> 'django.contrib.messages.storage.user_messages.LegacyFallbackStorage' > > Really? Files definitely seem to be more on the "storage" side of things: > > http://code.djangoproject.com/browser/django/trunk/django/core/files/storage.py The problem we have here is that we have all sorts of inconsistencies introduced by history. Yes, files and templates use function/class level specifiers, but db, session, cache, and email all use module level specifiers. Module level specifiers have the majority at this point, and personally, I prefer the module approach - it shortens the user configuration strings, and it enforces good usage of modules. My point is that I think we should pick an approach and stick with it. Long term, we should aim to be consistent. For example, #6262 gives us the opportunity to normalize template loaders into a common scheme. > Other than the question about renaming storage -> backend I think we > are close to prime time. Let me know what you think. I agree (though I'd also put the test location on that list). Although both require code changes, they aren't major code changes. Modulo those changes, I'm happy. Yours, Russ Magee %-) -- 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.
