PREVIOUS HOME NEXT

Test Examples

Requirements

Every test file is an XML file that must conform to the XML Schema Descriptor file "BlitzSchema.xsd" (located in the %BLITZ_HOME%\config directory).  Blitz will use this schema file regardless of whether you explicitly reference it in the XML file, so technically, you do not need to include the reference in your XML file if you don't want to.  However, if you wish to build test files through a schema-validating XML editor (such as XMLSpy, for example), then you will have to include the reference in your XML file.  In that case, your file will begin with the following two lines:

<?xml version="1.0" encoding="UTF-8"?>
<[testType]
    xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
    xsi:noNamespaceSchemaLocation="[uri-path]BlitzSchema.xsd">
....
</[testType]>

where [testType] is one of testScenario, testSuite, or testCase, and [uri-path] is the actual location of the BlitzSchema.xsd schema file.

TOP

Test Case

The following xml-file represents a sample test case specification:

<?xml version="1.0" encoding="UTF-8"?>
<testCase>
  <name>Test Case Example</name>
  <description>This is an example of how to set up a test case.</description>
  <property>
    <key>MY_KEY</key>
    <value>my value</value>
  </property>
  <inheritance>
    <property>NONE</property>
    <matcher>ROOT</matcher>
  </inheritance>
  <commandList>
    <file>bugcommands.txt</file>
    <command>verify bug QQ12345 mybug</command>
    <command>delete bug QQ12345</command>
  </commandList>
</testCase>

This test case specifies:

  1. One new key-value pair in the property element.
  2. Inheritance data, with the following declarations:
    1. NONE for properties, which means that only the individual properties defined in this test case will be in effect.
    2. ROOT level inheritance for matchers, which means that the test will use the first matcher it finds amongst its ancestors, and if none is defined above, it will use the NullMatcher.
  3. A command list, each one a string that will be interpreted by the IOperative at run-time:
    1. one file attribute, which indicates that the text file bugcommands.txt will be read in first
    2. two specific commands, each of which will be added to the command list for this test case
  4. Since no agency is specified for this test, at run-time, Blitz will search the ancestral hierarchy to find an agency; if none is found, Blitz will terminate with an exception.

TOP

Test Suite

The following xml-file represents a sample test suite specification:

<?xml version="1.0" encoding="UTF-8"?>
<testSuite>
  <name>Test Suite Example</name>
  <description>This is an example of how to set up a test suite.</description>
  <property>
    <file>c.properties</file>
  </property>
  <loopDuration>5H30M</loopDuration>
  <testFile>anotherSuite.ste</testFile>
  <testFile>aTestCase.tst</testFile>
</testSuite>

This test suite specifies:

  1. One property file (c.properties) which, depending on the inheritance values specified for individual test cases "owned" by this suite, might override other property values further up the test hierarchy.
  2. Looping parameters: the loopDuration attribute specifies a duration of "5H30M", which means that the tests in this suite will execute repeatedly for a time period of 5 hours and 30 minutes. Since no execution mode attribute is specified here, the tests listed will run according to the value specified in the system properties, or sequentially if no value is defined there.
  3. Two test files (anotherSuite.ste and aTestCase.tst). The first of these is a test suite; the second is a single test case. The contents of these files are read in and parsed at run-time, contributing to a bigger and more complex test suite.

TOP

Test Scenario

The following xml-file represents a sample test scenario specification:

<?xml version="1.0" encoding="UTF-8"?>
<testScenario>
  <name>Test Scenario Example</name>
  <description>This is an example of how to set up a test scenario.</description>
  <agency>
    <className>com.mypackage.MyAgency</className>
    <argument>initialization argument</argument>
  </agency>
  <property>
    <file>a.properties</file>
    <file>b.properties</file>
    <key>APPLICATIONNAME</key>
    <value>myapplication</value>
  </property>
  <concurrent/>
  <loopTimes>10</loopTimes>
  <testFile>x.ste</testFile>
  <testFile>y.tst</testFile>
  <maximumFailures>10</maximumFailures>
</testScenario>

This test scenario specifies:

  1. The agency named com.mypackage.MyAgency. This class is visible to all child-level test suites and test cases and is used automatically by any of the nested tests that do not explicitly specify their own agency. Note that this particular class expects to receive a single string argument (in this case consisting of the phrase "initialization argument") in its getOperative() method.
  2. Two property files (a.properties and b.properties) as well as two individual property declarations. At run-time, a.properties will be loaded, followed by b.properties; any property values in b.properties that have the same key name as values in a.properties are replaced by the new values. The individual properties (for example, APPLICATIONNAME=myapplication) are then applied to the property sheet and further override properties that have the same key name.
  3. Concurrency: the two test files are expected to be executed simultaneously.
  4. Looping parameters: in this case, the test is expected to be executed a total of 10 times. (For clarity, this means that the two test files are executed concurrently a total of 10 times.)
  5. Two test files (x.ste and y.tst). The first of these is a test suite; the second is a single test case. The contents of these files are read in and parsed at run-time, contributing to a bigger and more complex test scenario.
  6. A value of 10 in the maximumFailures attribute, which tells Blitz that it must terminate all tests as soon as the total number of failures exceeds 10.
  7. The test scenario does not specify any form of matcher, so, unless that attribute is specified at a lower level, the only matcher actually used will be the the one specified in the system properties, or NullMatcher if none is defined there. Similarly, there is no specification for the maximumErrors attribute, so the test scenario will terminate at the first occurrence of any error.

TOP

PREVIOUS HOME NEXT