Folder Directory Hierarchy


Prev		Next

We organise the test cases using a structured directory hierarchy to ensure consistency and clarity during testing. This organisation supports the efficient targeting of individual defined structures, for example, when testing the role attribute for abstract elements in our DocBook schema, the test case components are organised as follows:

Example 2. Tree diagram that breaks down the file directory structure of test cases

+---bloomsbury-mods-tests 
¦   +---condition-attribute 
¦   ¦       fail.xml 
¦   ¦       pass.xml 
¦   ¦        
¦   +---outputformat-attribute 
¦   ¦       fail.xml 
¦   ¦       pass.xml 
¦   ¦        
¦   +---relation-attribute 
¦   ¦       fail.xml 
¦   ¦       pass.xml 
¦   ¦        
¦   +---role-attribute 
¦   ¦   +---abstract 
¦   ¦   ¦       fail.xml 
¦   ¦   ¦       pass.xml 
¦   ¦   ¦        
¦   ¦   +---address 
¦   ¦   ¦       fail.xml 
¦   ¦   ¦       pass.xml 
¦   ¦   ¦

Example 3. Abstract Defined Structure

db.abstract.role.attribute = 
      attribute role { "blurb" | "authorAbstract" | "extract" } 
        db.abstract.attlist = 
          db.abstract.role.attribute 
          & db.common.attributes 
          & db.common.linking.attributes

Each test case is designed to validate against a specific defined structure, so in this instance, not only does it test a list of attributes that an abstract element can have, but the test also validates that the role attribute of abstract elements conforms to one of the following allowed values:

blurb
authorAbstract
extract

Although the test cases can be individually targeted during testing, which should significantly reduce the processing time, they are also designed to be valid when run against the entire test suite. Executing the whole suite ensures comprehensive regression testing, flagging if new modifications to the schema have inadvertently broken existing functionality.