== Problem: Testing == #none Rainbow desperately needs testing because introducing Rainbow into the software stack causes a number of fundamental changes in the mechanism by which activities are started. What evidence can we afford to collect on the actual effect of the changes we're trying to introduce? Situation: There are two scenarios that we're trying to manage, namely, `stable' and `devel'. `Packaged' Scenario: The problem here is to verify that a given version of the `olpc-security' package is complete and correct with respect to the appropriate `olpc-security-tests' package on a given `stable' configuration. In particular, we wish to verify that all the dependencies of the olpc-security package are available in appropriate versions and that the installation packages behave identically to the unpackaged development code, as sampled by the tests in the `olpc-security-tests' package. `Unpackaged' Scenario: The problem is to make it fast and easy to run the tests in the olpc-security-tests checkout with respect to the development configuration, which consists, to a first approximation, of a possibly modified base image, a kernel image, an initramfs, and a working-copy for each of the dependencies of olpc-security, one of which will be a working-copy of an olpc-security-tests package. The testing itself that we want to do isn't particularly hard: to a first approximation, there are three properties we wish to test: item conf. type desc. 1) (S) [I] Check that our packages cleanly install, 2) (S) [R] Check that all installed activities run for 30 seconds without crashing, 3) (D,S) [F] Perform both positive and negative checks on our P_* features, and later, their combinations. Plan: Herbert has shown Michael how to use QEMU to run sugar images, so we can actually address these scenarios in a reasonable way by automating the process of assembling the pieces. Followup: Help?