coapp-developers team mailing list archive

[Nasser Dassi <nasserd@xxxxxxxxx>]

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 <garretts@xxxxxxxxxxxxx>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*: garretts@xxxxxxxxxxxxx
> *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     : coapp-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~coapp-developers
> More help   : https://help.launchpad.net/ListHelp
>
>