03.03 - Resource Components

Resource, repository and target

Instructions and shortcuts are using resources (TA resources) and targets (Targets to test). Resources are included in repositories (librairies of resources).
There is 3 kind of resource components within Squash TA:


A TA resource is a data. More precisely a resource is a container which includes certain content (the data) and a category which qualifies the type of data. A resource may come from various origins: your own test data, results from the SUT, or derived from another resource. Right from the beginning Squash-TA defines a category of  TA resources: the File resource. A File resource is the basic category of resource, and is nothing more than a handle on a file somewhere. This type of resource is very common in TA scripts since any resource loaded from a repository (see below) will first be assumed to be a File resource before it can be converted to a more appropriate type. (Examples of resource categories: File, xml, script.sql...)
When a resource is created, it's created in a specific context and is available only for this context. (See below Test context / Ecosystem context)


A repository represents a location of physical resources. These are the media through which you will access your data and bring them in the Test context as File resources. Repositories are read-only by design: their content cannot be altered by a script execution. It's defined by :
    • A '.properties' file. The name of the file will be the identifier of the resource repository in the test context
    • Only one resource repository must be defined per file '.properties'
    • Repository categories: URL, FTP, classpath
Some kind of examples we can find in the 'repository' directory of an automation project:

example 1 : ftp_example.properties


example 2 : url_example.properties



Targets represent the SUT (System Under Test). They may stand for a http, a ftp server, a SSH server or a database. They may be read-write. It's defined by:
    • A '.properties' file. The name of the file will be the identifier of the target in the test context.
    • Only one target must be defined per file
    • Target categories : database, URL, FTP, SSH

Some kind of examples we can find in the target directory of an automation project:

Example 1 : 'yahoo.properties'


Example 2 : webcalendar_DB.properties'


Foreword about repositories and Targets configuration

Every repository and target are configured using a .properties file dropped in the 'repositories' / 'targets' directory of your test project. Each file will create one instance of the corresponding repository / target, and the name under which they are published in the Test context is the name of their configuration file minus the extension (i.e., if the configuration file is 'myrepo.properties', the name in the Test context is 'myrepo').

Every repository and target in the plugins shipped by default in Squash TA framework supports overrides using system properties. If you don't know what it means just skip the rest of this section. Combined with the configuration file itself, a repository can read its configuration from three levels:
  • 'Prefixed' system properties,
  • The 'Normal' configuration file itself,
  • 'Default' system properties.
Those level are hierarchical: 'Prefixed' > 'Normal' > 'Default'. The higher level at which a property was found defines the definitive value of that property. As an example, consider a property: 'squashtest.ta.my.property', defined in a file named 'myrepo.properties'. The following ways to set that property are all legal:

 level property name
 declaration location
 'Prefixed' myrepo.squashtest.ta.my.property system properties
 'Normal' squashtest.ta.my.property configuration file
 'Default' squashtest.ta.my.property system properties

As you can see the 'Prefixed' level reads a meta property which simply results from appending the property to the name of the Repository or Target (not the full name of the file, 'myrepo.properties').

Test context / Ecosystem context 

As said before, an ecosystem is a suite of test cases which have in common a setup phase and a teardown phase.From this, we can figure out two distinctives execution context. The context of a test case: the test context and the context of an ecosystem: the ecosystem context.

The test context is the pool where are gathered the resources for the duration of one single test. Resources can be retrieved from the Test context using its name whereas the ecosystem context is the pool where are gathered the resources for the ecosystem Setup AND for the ecosytem Teardown. In other words, resources created in the ecosystem setup are available in the ecosystem teardown too whereas resources created during a test case are available only for this test case.

Identifiers (names in the context)

Almost anything in the test context has an identifier. Valid identifier for a Resource, a Target or Engine Component are made of :
  • Any lowercase or uppercase a-z letters, digits,
  • Dashes '-', underscores '_', dots '.' and slashes '/'
Examples of valid identifiers: my_resource05      Another.Test.File        testfolder/My_File.txt
Example of invalid identifier: <-no space allowed $��}{�# etc <-uncommon characters

In particular, no space are allowed. Corollary, you should avoid to put in your test project any file or folder that does not comply with those rules.

When it comes to Resources, a good convention is to mention in the identifier what kind of Resources they actually are. For instance when loading a file, a good name would be 'my_resource.file'. This is not mandatory but it really helps.

In the rest of this document we will commonly use 'name' as a synonymous for 'identifier'.

Reserved names / identifiers

There is in Squash TA two reserved names / identifiers (for context parameters feature introduce ins Squash TA framework 1.8.0) :
  • context_script_params
  • context_global_params
Note that the framework doesn't prevent you to define your own TA resource with those context names in a test, BUT in this case they hide the previous resources (and a warn is logged).