How should we test fluid-all.js?

[Colin Clark]

Hi all,

We're talking through our best choice for ensuring good QA test  
coverage for our release package. This is the email Justin sent awhile  
back to lay out a few of the options on his mind. I've moved this  
table into a wiki page for easier reference:

http://wiki.fluidproject.org/display/fluid/Release+Package+QA+Test++Plan#ReleasePackageQATestPlan-IdeasforTestingtheReleasePackage

At this point, we're leaning towards an option that takes advantage of  
our new build system coming in Infusion 1.0.

Colin

On 12-Feb-09, at 1:46 PM, Justin wrote:

>
>
> Begin forwarded message:
>
>> From: Anastasia Cheetham <a.cheetham at utoronto.ca>
>> Date: February 12, 2009 1:46:06 PM GMT-05:00
>> To: Justin Obara <justin.obara at utoronto.ca>
>> Subject: Fwd: How should we test fluid-all.js?
>>
>>
>>
>> Begin forwarded message:
>>
>>> From: Justin <justin.obara at utoronto.ca>
>>> Date: January 16, 2009 12:42:01 PM GMT-05:00
>>> To: Fluid Work <fluid-work at fluidproject.org>
>>> Subject: How should we test fluid-all.js?
>>>
>>>
>>> We are attempting to find an optimal method for testing the  
>>> release bundle.
>>>
>>> The test plan is currently located on the wiki:
>>>
>>> http://wiki.fluidproject.org/display/fluid/Release+Package+QA+Test++Plan
>>>
>>> The main problem lies around how to test fluid-all.js. Below is a  
>>> table of possible methods and their pros and cons. Please feel  
>>> free to add new ideas, pros, cons, or to vote for which one you  
>>> think is best.
>>>
>>> Thanks
>>> Justin
>>>
>>>
>>>
>>> Method
>>> Pros
>>> Cons
>>> Manually change all dependencies to fluid-all.js
>>> 	• Manually ensure that all files have dependencies changed
>>> 	• Doesn't require any additional files or new samples be developed
>>> 	• error prone
>>> 	• time consuming (40 files * 2 packages = 80 places to change)
>>> Minimal set of sample pages that we manually change (e.g. mock-ups)
>>> 	• Will reduce the time and error
>>> 	• Will provide examples of fluid components working together on a  
>>> single page
>>> 	• May clutter the example page
>>> 	• Still have the risk of error when manually changing the  
>>> dependencies
>>> Automated process to modify the dependencies on each page.
>>> 	• Will eliminate most of the risk of error
>>> 	• Fast
>>> 	• Will have to be executed on the test system instead of the  
>>> final bundle being posted
>>> 	• Introduces another layer, which may be a source of errors
>>> The build process builds 4 different bundles, 2 using fluid-all.js  
>>> and 2 that don't
>>> 	• Part of the bundling process
>>> 	• Fast
>>> 	• Should eliminate the risk of most errors
>>> 	• Will build additional bundles that will likely only be used for  
>>> testing. Fluid.js in the bundles that are posted haven't been  
>>> tested.
>>> Minimal set of test files that actually link to fluid-all.js in  
>>> the repository.
>>> 	• Can test fluid-all from the build site if needed
>>> 	• No risk of error
>>> 	• overhead to maintain and update
>>> 	• developers would require fluid-all.js on their system in order  
>>> for these examples to work
>>>
>>> _______________________________________________________
>>> fluid-work mailing list - fluid-work at fluidproject.org
>>> To unsubscribe, change settings or access archives,
>>> see http://fluidproject.org/mailman/listinfo/fluid-work
>>
>> -- 
>> Anastasia Cheetham                   a.cheetham at utoronto.ca
>> Software Designer, Fluid Project    http://fluidproject.org
>> Adaptive Technology Resource Centre / University of Toronto
>>
>
> _______________________________________________________
> fluid-work mailing list - fluid-work at fluidproject.org
> To unsubscribe, change settings or access archives,
> see http://fluidproject.org/mailman/listinfo/fluid-work

---
Colin Clark
Technical Lead, Fluid Project
Adaptive Technology Resource Centre, University of Toronto
http://fluidproject.org