Organizing Tests into Suites

Overview

Unless you specify otherwise, stride will publish results from all of your test units into a single top-level test suite when run. This is a satisfactory arrangement as long as the number of tests is relatively small. As the number of test units grows, or test units from disparate groups are aggregated (as in a Continuous Integration arrangement) this flat report organization becomes hard to use.

The software under test itself is typically broken up into separate units (e.g. libraries, components, objects, etc.) and organized into a hierarchy that reflects the functional organization of the software. If the results from STRIDE tests could be organized identically to the software under test, ****.

• Subtotals of Time Under Test, Pass/Fail and Error counts are provided for each suite

Organizing Into Suites at Test Runtime

[-r omitted]
-r /(TestUnitName)
-r /suite1/suite1.1/suite1.2(TestUnitName)

Techniques for Organization

• Name your test units such that their organization is implicit

level1_level2_level3_name

• Have each subgroup manage their own file.

OrganizeIntoSuites.pl

#!/usr/bin/perl
use strict;
use warnings;

# set this to your separator character or string
my $token = '::';

while( <> ) {
    chomp;
    my @segments = split(/$token/);
    # remove the last segment from the array
    my $testunit = pop @segments;
    print "-r /";
    foreach my $segment (@segments) {
        print "$segment/";
    }
    print "($_)\n";
}

Batch File or Shell Script

stride --list --database TestApp.sidb | perl OrganizeIntoSuites.pl > TestsInSuites.txt
stride --database TestApp.sidb --device TCP:localhost:8000 -O TestsInSuites.txt