coapp-developers team mailing list archive

[Garrett Serack <garretts@xxxxxxxxxxxxx>]

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.

[Description: fearthecowboy]<http://fearthecowboy.com/>

Garrett Serack | Microsoft's Open Source Software Developer | Microsoft Corporation
Office:(425)706-7939                                       email/messenger: garretts@xxxxxxxxxxxxx<mailto:garretts@xxxxxxxxxxxxx>
blog: http://fearthecowboy.com<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.