For testing, I usually go with the "everything's a failure until the few success use-cases actually succeed" mantra.
That being said, basic testing parameters should be based on OS, architecture, and security clearance (admin or std-user). Individual tools/libraries could get rated based on expected input-output (to give some leniency prior to "absolute failure"). All other testing criteria would be contingent on the tool/library's narrow purpose. The GUI would get tested based on environment factors, too.... but i'm not too big a fan of absolute TDD/Unit Testing prior to writing actual code. - nasser On Wed, Apr 21, 2010 at 11:44 AM, Garrett Serack <[email protected]>wrote: > I know this is early, but I’d like to get some ideas rolling around > testing. > > > > We’re going to be writing a few different classes of software for CoApp: > > > > (a) A collection of command line tools/libraries (+msbuild plugins) to > automate the tasks of adapting source code to Windows, and building > packages. (Trace, ScanTool, mkSpec, mkProject, PGOMagic, mkPackage, > SmartManifest) > > (b) A client service that handles the nitty-gritty details of managing > the dependencies, shared libraries, updates and consistency & validation > (essentially all the brains under the UI) (SharedLibraryConfig) > > (c) A client GUI application that is the primary UI that end-users > interact with (like synaptic) > > (d) A command-line client for those of us with too many years at the > keyboard & still like to script (like apt) > > (e) A Visual Studio plugin for developers > > > > > > Ideally, we should have a plan for testing these—although items in category > A don’t lend themselves to easy testing. > > > > Category B is critical to be heavily tested and security audited, and we’re > going to have to go to town on that. Plus, it seems easy to me to understand > how to write automated tests for it. > > > > Category C & D—and to a certain extent, Category E—are pretty lightweight > and I think of them as wrappers around the services that Category B > provides. I suppose these are testable, but to what point? > > > > I’d like to hear what ya’ll think about strategies for handling testing of > A/CDE. > > > > [image: Description: fearthecowboy] <http://fearthecowboy.com/> > > *Garrett* *Serack* | Microsoft's Open Source Software Developer | *Microsoft > Corporation > Office*:(425)706-7939 *email*/* > messenger*: [email protected] > *blog*: http://fearthecowboy.com * > twitter*: @fearthecowboy <http://twitter.com/fearthecowboy> > > *I don't make the software you use; I make the software you use better on > Windows.*** > > > > > > _______________________________________________ > Mailing list: https://launchpad.net/~coapp-developers > Post to : [email protected] > Unsubscribe : https://launchpad.net/~coapp-developers > More help : https://help.launchpad.net/ListHelp > >
<<image001.gif>>
_______________________________________________ Mailing list: https://launchpad.net/~coapp-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp
