Ok, to make sure I understand: When I install a package on my site, it's identified by a package key. When I choose "new application" in the site map, I'm creating an instance of that package (with its own, unique package_id) and, simultaneously, mounting it. A "package-aware" application should partition its data by package_id. I can mount the application in several places, and all will point back to the same code and the same data slice. If I create a new application with the same package, the applications will share code but not data.
Thanks for the db examples; I was hoping to use a function instead of writing new code to dig out basic information, but ah well. I guess there isn't much perceived need to do this sort of thing?
So. To address both of the previous posts at once: IMHO, it should be possible to aim the test suite at any application - at any instance of a package. Reasons:
1) The test suite, or at least a subset (maybe the 'smoke-test' portion, maybe a 'data-safe' category, should be reasonably safe to run on a live package, so that it can be used for diagnosis of problems.
2) The full test suite should be run on new applications to make sure that they work.
3) There might also be a version of the test suite that runs against functions, not pages. It would be used for other types of testing, such as before the UI is built, or if a custom UI breaks the automated test.
Whenever possible, tests should go through the UI and use the full http_request/parse the results approach, because this is the most comprehensive testing and can catch the most errors.
