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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
