Testing With Workflow

Testing With Workflow

The Snow is white, lite and may cover everything. SnowTest is intended to be simple, lightweight, easy to use and good for several purposes, focusing mainly on the basic and critical test scenarios. Being based on WWF 4.0 it might be applied to Service or UI level tests as well: anything can be controlled from C# can be designed as a workflow. The examples below are NUnit based tests, but the hosting test framework is not a restriction for the SnowTest framework.

* I am sorry for the quality of the movies below. I uploaded high quality mp4 files which have been converted into flash. In case you know the way I could keep the original quality, please share that information with me. Thank you in advance. I hope the concept can be understood even without being able to read the texts.

1. Test Cases as WWF 4.0 Workflows

Sometimes I felt useful having a visual representation of some complex test cases. That is why I tried to model them as WWF 4.0 Workflows.

Test Cases as Workflows

2. HelloWorld Test

As many tutorials start with 'HelloWorld' examples I created a 'Hello World' test case.

Hello World Test

3. Data Driven Testing

The DDT support is really necessary when the same execution&validation logic should be executed for different input data values.

DDT Support

4. Activity Reuse

One of the main benefits of encapsulating the Test Steps into Activities is the possibility of reusing them easily.

Test Step Reuse

   

5. Test Steps Executed in Parallel

Sometimes it migth be necessary to run Test Steps in parallel. Writing asynchronous activities migth be inconvenient. The reuse of the already written synchronous activities is supported by asynchronous container activity.

Parallel Test Steps

6. Scalability Tests

In order to simulate concurrent scenarios in a simple environment another type of hosting activity is provided by the framework. One might monitor the performance characteristics of a feature when being used by many clients at the same time.

 

MultiClient Tests

7. Concurrency Tests

Similar or inhomogeneous scenarios, distributed randonly on the time axis (as it happens in the real life when many clients are using the same system) is also supported. Thsi functionality is useful when some features may have impact on others (for example Read & Write, Store & Delete & Modify).

MultiClient MultiScenario Tests 

8. Stability Tests

Support for stressing the system for a long time with a diversity of test cases is welcome especially when the stability of the system should be proven.

Long Runing System

 9. Acceptance Tests

The requirement engineers can be involved in testing while defining the requirements. The developers and test developers will always be kept in sync with the expected behavior of the system. Requirement & Acceptance Test at the same location!

Acceptance Test Driven Requirement Engineering