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:

Resource

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)

Repository

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

squashtest.ta.ftp.host=192.168.2.24

squashtest.ta.ftp.username=squash

squashtest.ta.ftp.password=squash

squashtest.ta.ftp.system=windows

squashtest.ta.ftp.port=21

example 2 : url_example.properties

squashtest.ta.url.base=http://repo.squashtest.org/maven2/releases/eclipse/jdtcore/

Target

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'

#!http

squashtest.ta.http.endpoint.url=http://www.yahoo.fr

Example 2 : webcalendar_DB.properties'

#!db

squashtest.ta.database.driver=com.mysql.jdbc.Driver

squashtest.ta.database.url=jdbc:mysql://localhost:3306/webcalendar-db

squashtest.ta.database.username=webcalendar

squashtest.ta.database.password=squash

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:

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.