A common pattern for larger applications is to maintain bits of reusable code outside of applications, but still inside of a project (e.g., myproject/lib), due to synchronous development and modification of application and library code. They're parts that aren't really large enough to warrant their own pip-installable package, but large enough to need tests.
Often, the (non-)solution is either to NOT test these small tools at all, or to test them in a way that tightly couples them to one's applications. I'm here to get feedback on the general idea of a solution to the aforementioned problem, and on the acceptability (by the community) of such situations (maintaining libs outside of applications but still inside of a project): 1) Is there merit to (Django) providing a way to specify a project-level tests package/module wherein tests could be imported from various places in your project? OR 2) Is this something that should always remain in a custom test runner? OR 3) Is this sort of code maintenance just not a great idea because libraries that need tests should be factored out as pip-installable packages and independently tested? If this is considered a good practice AND the answer to #1 is something akin to "yes", feel free to make suggestions on what you think the API (or setting, etc.) should look like. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
