How should we test fluid-all.js?

Michelle D'Souza michelle.dsouza at utoronto.ca
Mon Jan 19 17:09:33 UTC 2009


I like the fifth option. This would mean that we'd have more eyes on  
the Fluid-all integrated code for the entire process instead of just  
testing the Fluid-all file at the end of a release. I think the  
minimal set of samples could be the 'shared' examples that we  
currently have - sakai and uPortal. We'd need to add components to  
those examples to cover everything or create a couple more shared  
examples.

Michelle


On 16-Jan-09, at 12:42 PM, Justin wrote:

>
> 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

------------------------------------------------------
Michelle D'Souza
Software Developer, Fluid Project
Adaptive Technology Resource Centre
University of Toronto



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20090119/aadb4d21/attachment.html>


More information about the fluid-work mailing list