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 - [email protected]
To unsubscribe, change settings or access archives,
see http://fluidproject.org/mailman/listinfo/fluid-work
