# from A. Pagaltzis
# on Saturday 18 August 2007 06:59 am:

>* Eric Wilhelm <[EMAIL PROTECTED]> [2007-08-18 02:25]:
>> Part of my original point is that it would be useful[1] to
>> define a standardized mapping of what functionality or
>> resources are required to run typical subsets:
>>
>>   author: some pod testing, kwalitee, etc prereqs
>>   network: network access
>>   gui: a gui
>
>What about author tests for the GUI? Or tests that need both the
>network and a GUI?

OR tests for pumping screenshots from the gui (run via a network 
connection to the author's machine) into a postgres database and 
uploading them to flicker?

Yes, it can get complicated.

No, it doesn't have to always be complicated.

What we have now sucks.

So, more complicated scenarios need more complicated configuration.  
This could be done via "the thing to be discussed in a different 
thread" (e.g. "a config-file plus 'use skipme' in the test" under the 
misc directory ("xt/misc/gui/foo.t" -- misc meaning that they are not 
easily classifiable and/or are externally/internally configured.))

The main goal (well, my main goal) is to have some kind of 
easy-to-understand recommendation for new authors (or even experienced 
ones) on how to organize their tests when the tests are considered 
optional[1].

I think a way to cover the basics with existing tools (without having 
everything totally ad-hoc) is important.

I would prefer that this doesn't involve skipping tests.  That is, there 
is less noise in the output if an optional test is never run than if it 
starts and then says "oops, no ignore me."  The tools should decide 
which tests to execute.

I would like to be able to categorize/sort/select tests without 
executing them.  I keep harping on this point because I think it could 
enable a much richer distributed testing environment.

[1] It seems that "optional" is a bit of a sticking point around here.  
Essentially, when resources required by those tests are likely to cause 
spurious failure or when failure of a given test is otherwise 
irrelevant to functionality or when the tests are testing optional 
features.

--Eric
-- 
"Matter will be damaged in direct proportion to its value."
--Murphy's Constant
---------------------------------------------------
    http://scratchcomputing.com
---------------------------------------------------

Reply via email to