I still think that including this meta data in each individual test makes it harder to discover what tests are being excluded - you now would have to search all the test files to find this information out instead of opening a single file in an editor and just looking.
I think this boils down to having a meta data feature that saves time for the test creator but that isn't the person who needs to deal with that piece of meta data at all. It's Dan and myself (or others in QA/Build Release) who have to turn off tests on demand. I just think that not having it in a central file location makes that task harder.
On Jun 7, 2007, at 8:52 PM, Mikeal Rogers wrote:
Unless you also remove wx from the tests this will not work for rt.py as it needs to run on the tinderboxes and they do not have wx installed.You can import the run_recorded module and run the get_test_modules which imports all of the test modules without wx or chandler being installed.When we were talking about this in the #QA channel on IRC I thought you were talking about a simple python file to just contain the tests to run or exclude and not about adding metadata to the tests themselves.The way we already had it was using the test metadata, we were talking about modifying it because it wasn't compatible with rt.py, my patch fixes that and rt can use the current test collector.Wouldn't this be simple to do as a tests.py file that is pure basic python that can be loaded by both chandler and rt and just contains an exclude list and then does a simple dir walk?I had a variety of reasons for going this route when I originally wrote it. The primary reason is that it's a lot cleaner to keep data about the tests in the tests. You can see all the changes and history of a test by looking at the svn history for that file, rather than having all the exclusion semantics in another file which you also have to keep track of.I don't know what "pure basic python" means. This is all python, all the ways we run a test can use the same code, it is more dynamic than the old way but it's written and working and, in my opinion, easier to maintain.-Mikeal _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev
--- Bear Build and Release Engineer Open Source Applications Foundation (OSAF) [EMAIL PROTECTED] http://www.osafoundation.org [EMAIL PROTECTED] http://code-bear.com PGP Fingerprint = 9996 719F 973D B11B E111 D770 9331 E822 40B3 CD29
PGP.sig
Description: This is a digitally signed message part
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev
