Design, Extensibility & Usage

Designed around a "pipeline" concept - you configure the pipeline with any number of steps then execute the pipeline with a context to get a result. The context acts as a "visitor" to each step and can convey data between steps or state of the overall test. You can provide your own custom context to the pipeline as the pipeline and steps are generics, where the step has a hard requirement on the context a generic type restriction is used to ensure your context is compatible. Just apply the interface to your custom context as required.
// eg: your context must support IWebContext in order to use this step
public class HttpStep<T> : StepBase<T>
        where T: IWebContext

Identify tests to verify your deployment and smoke tests that "prove" the system works; use the provided components or build custom components to arrange and assert it's all working - build tests to provide sufficient coverage and confidence to commit to more in-depth testing.

Finally bundle your test assembly with your test runner console app and a batch file - give it to your testers and let them run these smoke/deployment verification tests after each deployment - these could also be easily automated as part of the deployment. The test runner apps usually have a pretty decent UI to show progress and failures.


There are several scenarios for executing these tests. Remote and Auto are two scenarios I am working on right now with new plugins to my other project "Wolfpack".
  1. Direct - you have direct access to the infrastructure resources that you need to interact with, eg: Database, Windows Services. These resources are exposed for external connection and can be manipulated from outside the machine or environment perimeter. The test package executes on a machine against resources in the target environment, typically these will be hosted on a different machine(s). Note whilst this setup is the most powerful/flexible it is also biggest security risk - I'm sure most places will have this locked down (unless VPN'd etc).
  2. Local - the test package is copied to the target machine/environment and executed against "local" resources (eg: tests run inside the environment perimeter).
  3. Remote - similar to the Local scenario - the test package is deployed locally to the target environment/machine but can be executed (locally) via a remote command.
  4. Auto - the test package is automatically downloaded and executed on the target environment/machine with results (failures) sent as notifications.

Last edited Aug 15, 2012 at 10:28 AM by jimbobdog, version 4


No comments yet.