How should we test fluid-all.js?

Justin justin.obara at
Fri Jan 16 17:42:01 UTC 2009

We are attempting to find an optimal method for testing the release  

The test plan is currently located on the wiki:

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.


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the fluid-work mailing list