==============================================================================
Author: Carl Nagle
Since: MAR 30, 2006
Update: AUG 20, 2010
Copyright (2006,2010) SAS Institute
http://www.sas.com
General Public License (GPL):
http://www.opensource.org/licenses/gpl-license.php
==============================================================================
Background Info, Design-Time Test Table Development, Advanced Runtime Development
Refer to:SAFS JavaDoc
The documentation of interest in the published JavaDoc is 'org.safs.model' package and subpackages. The sourcecode and compiled class files for the JSAFS API Model are all provided in the safsmodel.jar provided with SAFS. Note, also, the JSAFSDriver intended for use in some advanced runtime frameworks and scenarios (discussed later).
Back To Top, Design-Time Test Table Development, Advanced Runtime Development
When the API is used as an "Advanced Runtime", the Java code *is* the test and it contains runtime calls to the SAFS framework to accomplish tool-independent test activities. There generally are no SAFS test tables created and all testing is driven from the developer's independent Java program.
While JSAFS is provided for Java test development, the code or applications to be tested are not limited to Java clients. You can develop tests for:
The most common SAFS engines are those written for:
Some other engine possibilities are:
JSAFS attempts to engage Java-savvy developers and testers exploiting tools like Eclipse and allows them to develop tool-independent SAFS tests in a familiar environment. It allows them to code tests that are still independent of the automation tools used at runtime. JSAFS leverages the Java IDE to provide a wealth of information and documentation to the JSAFS test developer.
The detailed information provided in the SAFS Keywords XML and the primary SAFS Reference is similarly encapsulated as Java functions and JavaDoc for each supported SAFS keyword. Thus, the Java IDE is able to present this information to the developer in a context-sensitive manner via the auto-complete, tooltips and popups they already know. Every SAFS command is available as a "callable" function. Documentation for commands, component types, available functions, and parameters are available in the IDE, as shown below.
Java is an especially well-supported interface into SAFS which means Java developers using JSAFS have nearly endless possibilities for how they can exploit SAFS. Other programming languages like VBScript, Perl, and C\C++ are also well supported, but do not have a comprehensive API interface to SAFS like JSAFS provides.
The potential for using JSAFS can generally fall into the two broadly-defined categories previously mentioned:
| Design-time Test Table Development: | Build tests that export tables for traditional SAFS processing later. |
| Advanced Runtime Development: | Use SAFS assets and engines controlled by your Java program at runtime. |
The developer's Java code does not actually "run" the tests. However, the developer can embed code to launch a suitable SAFS runtime after the tests have been exported.
For the following discussion, refer to the 'org.safs.model' package JavaDoc.
You will see in the model package we have both abstract and concrete classes that represent the various pieces of a SAFS test. There are classes that represent the various record types like Driver Commands and Component Functions. There are classes that represent the different types of test tables: Cycle, Suite, and Step. There is even a 'Variable' class that represents a SAFS variable (a.k.a. DDVariable).
Now refer to the 'org.safs.model.commands' and the 'org.safs.model.components' package documentation.
The 'components' package provides a means to represent your application GUI components in a JSAFS object that knows all the commands that can be executed on that type of component. The 'commands' package provides similar classes that allow you to call the same commands in an alternative manner. This is to accomodate different developer preferences.
For example, some developers have chosen to use Java Collections, Arrays, or even external sources to store or otherwise encapsulate application test data. Some use Java to loop through that data exporting a separate test record--or table of records--for every item to be used in the system. Further, they do the looping of the data in Java code to create 50 new hardcoded records for adding 50 new users and do NOT use any looping in the SAFS runtime. They do NOT use any global SAFS DDVariables--everything is hardcoded and linear in the exported test tables.
It sounds like a worst-case scenario for reuse, but it is not in most cases. For this scenario it is the JSAFS Java code that is the reusable asset, not the linearly hardcoded SAFS text files exported, executed, and ultimately discarded. There is not necessarily anything wrong with this in a JSAFS-only test. As the external data changes over time, the exported runtime test tables will reliably change along with the data.
Integrating with other non-JSAFS assets:
These JSAFS tests do not have to live in a JSAFS-only world. There may be developers writing JSAFS tests in their environment that must integrate with and have dependencies on SAFS tests developed in Access, Excel, TextPad, or some internal corporate proprietary tools.
Because the output of all of these are SAFS-compatible test tables, JSAFS tables can call Excel-based tables, and vice-versa. All that matters is that each tool has exported its test tables prior to execution. Once all the tables are in place, any table can call any other table because they are all compatible and ready for execution.
Such an environment may or may not require JSAFS table exports to be more reusable like those traditionally developed by other methods. That would be up to the collaborating team of testers and developers to decide and design into the overall test solution.
Refer to the sourcecode in the 'org.safs.model.examples.tables' package and its subpackages for some simple examples of putting the JSAFS API to use. The sourcecode for the examples is also available in the safsmodel.jar file delivered with SAFS.
The sourcecode examples represent just a few ways in which JSAFS tests could be constructed using Design-time Development. More examples will become available over time. Now, let's take a look at the much broader possibilities provided by customizing SAFS with JSAFS Advanced Runtime Development.
One possible mechanism for using JSAFS in this way is for the new custom Java class to be a direct subclass of SAFSDRIVER, or its superclass: DefaultDriver. By doing this, the developer inherits all the core startup and initialization capabilities of SAFSDRIVER--including the startup of required SAFS services and engines. In addition, the custom SAFS driver has easy API access to all the SAFS services for handling variables, appmaps, NLS, and logging. The new driver will also inherit the running SAFS Monitor allowing the tester or developer to Pause, Resume, Step, and Shutdown a running test, if desired.
However, it is also possible to merely add a comparable JSAFSDriver to any Java class or testing framework. The developer still acquires all the core startup and initialization capabilities of standard SAFS Drivers--including the startup of required SAFS services and engines. The custom driver will still have access to SAFS Monitor allowing the tester or developer to Pause, Resume, Step, and Shutdown a running test--assuming the developer exploits this feature in their code. In addition, the JSAFSDriver provides convenient API access to all the SAFS services for handling variables, appmaps, NLS, logging, and expression handling.
Commented example(s) with sourcecode are provided in the org.safs.model.examples.advanced package. The sourcecode can be found in the safsmodel.jar file in a SAFS\lib directory.
The JSAFSDriver main(String[] args) sourcecode can also act as an example since it is a functional self-test of the class itself:
Sample Advanced Runtime Java Code.