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 <[email protected]>
Date: February 12, 2009 1:46:06 PM GMT-05:00
To: Justin Obara <[email protected]>
Subject: Fwd: How should we test fluid-all.js?
Begin forwarded message:
From: Justin <[email protected]>
Date: January 16, 2009 12:42:01 PM GMT-05:00
To: Fluid Work <[email protected]>
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 - [email protected]
To unsubscribe, change settings or access archives,
see http://fluidproject.org/mailman/listinfo/fluid-work
--
Anastasia Cheetham [email protected]
Software Designer, Fluid Project http://fluidproject.org
Adaptive Technology Resource Centre / University of Toronto
_______________________________________________________
fluid-work mailing list - [email protected]
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
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://fluidproject.org/mailman/listinfo/fluid-work
