What is a Session?

A session represents actions on a single Application. A TestCaseTag can contain multiple sessions or SessionTags. SessionTag is abstract since the state it keeps across a single application will depend on the type of application (web application, GUI application, console application). A web application keeps the state of the application via cookies or url rewriting. This requires some sort of interface that mimics the behavior of a browser. However, a GUI application's state or session is kept track of via the application itself which would need a different interface to connect directly to the applications functionality.

Session Tag Common Attributes

All SessionTags have the same basic properties available to them:

Property Name:DescriptionRequired
application

This is set to the name of the application this session will be executed against. Values from the testEnvironment-Applications.properties file are extracted based on keys that start with the name of this application.

For example, if the application name is "google" and the testEnvironment is set to "alpha" then the session will look for the file alpha-Applications.properties in the CLASSPATH. The file is in the normal properties file format (key=value), one key=value per line in the file.

If the organization is set, then the organization goes before the application name when defining the variable. In other words, if test case "SubmitSearch" needed to set a variable "searchTerm" to "Jameleon" for organization "sourceforge", and application "search", then the variable name or key would be "sourceforge.search.searchTerm=Jameleon". If organization is not set, then the definition would look like: "search.searchTerm=Jameleon"

If the testEnvironment was set to alpha, then this variable would need to be defined in alpha-Applications.properties. Any variable can be set this same way. If a variable is set in the testEnvironment-Applications.properties file, then that variable will be available for all test cases that test the corresponding application.

Both the HttpUnit plug-in and the JWebUnit plug-in look for two variables to be set:
  • baseUrl - The full hostname ( http://www.google.com/ ) - HttpUnit plug-in only requires this to be set.
  • beginAt - The url that proceeds the baseUrl for this application. This is only required by jWebUnit.
No - however, if planning on using Applications.properties, an application MUST be set.
organization

The name of the organization the test case is to be executed against. Only use this if the test case involves testing different applications ( therefore sessions ) where one or more of the applications requires execution in an organization different from the one set in the test-case element.

This might be used for a test case that has multiple sessions and applications that it is testing. Most of the applications are run against organization "sourceforge", but one of the applications only exists against "freshmeat". Under this scenerio, organization would set to "sourceforge" in the test case element, and all of the applications that were to be tested against that organization would not define organization at the session level. Only the application that was to be tested against "freshmeat" needs to define the new organization in the session element. The value of organization also influences the location of the data file.

If the organization is set, the test case will look for a CSV file in the etc/testEnvironment/organization directory. For example, when a test case with name set to "ExampleTestCase", testEnvironment set to "stg", and organization set to "ACME" is executed, it will look for a file "etc/stc/ACME/ExampleTestCase.csv.

No
beginSession

This is used to tell the session tag to start the application in the state provided.

No
sessionDelay

This is used to tell the session tag to wait x milliseconds before any other child tags are executed. This is useful for when a task to validate takes some time before completion.

No

Session Plug-in Implementations

Each plug-in must implement their own session tag. The current plug-ins are listed to the left. Please click on the appropriate plug-in for specifics as to how to write tags for that particular plug-in.

Please refer to the section on the attributes supported by the base SessionTag here.

Writing a Session Tag

Developing a plug-in requires implementing a session tag. Users of plug-ins may skip this section. For the most part, the steps to develop a session tag are documented in the javadocs for SessionTag. Please refer there for now.

Developing Session Tag Tips

Some things to keep in mind when developing a session tag.

  • The plug-in's session tag should not require an extension to use.
  • Everything it needs should be configurable via the script itself.
  • If the application type being tested requires some sort of handle, then create an instance variable which represents this handle and create corresponding public set and get methods for it.