Project

General

Profile

Testcases

Introduction

This publicly available testcase project is meant to be a comprehensive set of 4GL compatibility testcases, written in a clean and managed manner. These testcases are meant to be fully automated and used for nightly 4GL compatibility testing of FWD. The intention is to eventually cover the full range of behavior of the 4GL. This is not yet achieved and likewise the tests are not yet fully automated. That work is ongoing.

Everything in this repository must be original work that is owned by GCD or properly contributed to the FWD project. No customer code, customer-specific references or otherwise encumbered code can be placed in this repository. All rules for Writing 4GL Testcases must be followed. If you need a location to save testcases which cannot be publicly shared or which are poorly constructed, please use the Old UAST Testcases repository instead.

Test Suite Setup and Conversion

1. Check out the project configuration:

bzr co sftp://<username>@xfer.goldencode.com/opt/testcases
cd testcases

2. Add the skeleton project:

bzr co ~/secure/code/p2j_repo/skeleton

3. Link FWD:

  • checkout a compatible p2j branch (probably not trunk)
  • make sure the project has been built by ./gradlew all
ln -s <path_to_your_branch>/p2j/ p2j

4. Configure ant:

  1. Edit prepare_build.json to match your database setup
  2. Run ./testcases_setup.sh to setup the build environment

5. Run reports OR conversion (note: at this time, we do not use a convert file list or ignore list).

Note: When new 4gl source files are added or p2j rebuilt, the whole process described in 4. should be repeated, server and clients restarted.

5a. Parse and run reports:

ant rpt

OR

5b. Run conversion:

Edit the file-cvt-list.txt to put the specific files in.
For example via find, for the field_io folder (and include the common folder):

find {field_io,common} -type f \( -iname '*.p' -o  -iname '*.cls' -o  -iname '*.w' \) -print > file-cvt-list.txt

and then convert the list:

ant clean convert.list

5c. Compile the sources

If the conversion completes, the generated Java source code must be compiled using:

ant jar

5d. Deploy the sources

If the compile completes, the generated Java source code must be deployed using:

ant deployapp

if you are utilizing the FWD_LIB environment variable to indicate where the FWD libraries build/lib directory is (for example export FWD_LIB=/opt/fwd/trunk). If you will be co-mingling the FWD jar files from the ../p2j/build/lib directory into the projects ./build/lib directory, you can use:
ant deploy

6. Execute a testcase.

Running a standalone testcase can be done either in the FWD Web client (for GUI and ChUI), the Swing client (for GUI and ChUI) or the native client. The project is configured to run each of these type of clients.

For the web client, is mandatory to specify the target test in the p2j-entry in directory.xml. p2j-entry will refer the legacy 4GL program name (with its path, relative to the abl/ conversion folder).

To setup the directory.xml, use prepare_dir.sh in the deploy/server directory.

  1. Edit ./deploy/server/prepare_dir.json to contain your testcase setup. The default version is typical of usage for H2. There is prepare_dir_postgres.json for PostGreSQL usage. Make sure to set {dbport} to the correct port value.
  2. Run ./prepare_dir.sh in the deploy/server directory. Usage:
    Usage: ./prepare_dir.sh [-o] [-f <json_cfg_file>]
    Where:
        f = input from [json_cfg_file] (def=prepare_dir.json)
        o = Overwrite the specified directory.xml, otherwise fail
    

The FWD server can be started from the command line using this:

cd deploy/server
./server.sh -d

Or you can start the server, executing the prepare_dir.sh script prior to startup with:
cd deploy/server
./start_server.sh -d -p

The -p option will run prepare_dir.sh using the current prepare_dir.json file. You can specify any json file with -p <json_file>

This will open the 2080 port for debugging purposes. If you want to start the FWD server from Eclipse or another IDE, check the output of ./server.sh -t and adjust your run settings in the IDE accordingly (classpath, JVM arguments, program arguments, main program, etc).

For standalone clients, ran via the deploy/client/client.sh or client.cmd scripts, you can add the client:cmd-line-option:startup-procedure=path/to/someProgram.p as a command line argument. Make sure to first convert someProgram.p and all its dependencies as described in 5b (also check the note in 5.).

6.a For a ChUI client in a terminal:

cd deploy/client-chui
./client-terminal.sh client:cmd-line-option:startup-procedure=path/to/someProgram.p

6.b For a GUI Swing client:

cd deploy/client-gui
./client.sh client:cmd-line-option:startup-procedure=path/to/someProgram.p

6.c.1 For a web client, access https://localhost:7443/gui or https://localhost:7443/chui and authenticate with the OS username and password.

6.c.2 To enter the Administration Console (to monitor the Lock Table for example), go to https://localhost:7443/admin and use credentials: admin / admin. This step works only if p2j has been built with ./gradlew all or ./gradlew ant-admin_build).

6.d - Extra info for executing testcases

6.d.1 The p2j-entry must be updated each time you want to run the FWD Web Client:

  • shutdown the FWD server
  • edit the prepare_dir.json configuration for the p2j-entry to the new program as noted in step 6 above.
  • restart the FWD server

6.d.2 To run a FWD Web Client or Web Service (REST/SOAP), the FWD server must be started from the command line (or, if using Eclipse or another IDE, add the path to p2j.jar to the classpath and remove the src/ folder as a source-folder). The reason is that the FWD Server and the spawner must use the same p2j.jar, to be able to launch the FWD client or appserver Agent.

7. Configure the spawner

For Web clients or Web services tests, it is mandatory to properly configure the directory.xml and install the spawner. The configuration of the directory.xml is done with prepare_dir.sh and the appropriate json configuration file. Then run ./install_spawner.sh with the correct parameters"

Usage: ./install_spawner.sh [-ad] [-s<path to place spawner>] [-p<path to FWD>] [-f<path to slf4j-impl.jar>] [-n<path to native spawner>] [-c<path to srv-certs>] [-t<path to postbuild.sh tool>]
Where:
a     = Copy *only* testcases libraries (prevents co-mingling of application and FWD libraries).
d     = Dry run. Just show commands.
s     = Destination directory to place spawner (def=/opt/spawner)
p     = Location of FWD libraries p2j.jar and fwd-slf4j.jar (if no -f specified). Override FWD_LIB, if set. (def=./p2j/build/lib)
f     = Location of file to be placed in slf4j-impl.jar destination (def=fwd-slf4j.jar in -p location or FWD_LIB)
n     = Location of built native spawner (def=/opt/fwd-deploy/spawner/spawn)
c     = Location of srv-certs.store file (def=/home/rfb/projects/testcases_v2_dev/deploy/server/srv-certs.store)
t     = Location of postbuild.sh tool (def=/opt/fwd-deploy/spawner/postbuild.sh)
Using the original deploy/server/prepare_dir.json, you will need to update these settings:
  • "client_start_dir": "../client", with the full path to the deploy/client folder
  • "spawner_path": "/opt/spawner/spawn", with the full path to the spawn application (usually /opt/spawner/spawn)
  • "os_user": "rfb", with the OS username of an account which has access to deploy/client folder

Once this is configured, install the spawner using the ./install_spawner.sh script. By default, this will install all required files to /opt/spawner folder. This folder can be changed, but is mandatory to update the "spawner_path": "/opt/spawner/spawn", to setup the directory properly.

Conversion, Configuration and Runtime details

Converting files

  • Create a simple helloworld.p program in the root directory:
    message "Hello world!".
    
  • Add this file (and any other files) to the file-cvt-list.txt file, relative paths to the root project folder.
  • convert and compile this program:
    ant convert.list jar deploy.prepare
    

Import the database

When the proper json file is used to configure the directory (prepare_dir_h2.json or prepare_dir_postgres.json), the -r <dbdump_path> option to start_server.sh will perform an import of the database specified in the configuration, located in the <dbdump_path> directory. The directory_db.xml.template is merged into the directory.xml with the proper values setup.

If you do not want to include starting the server with importing the database, the ./importdbs.sh script in the deploy/server can help. Usage:

Usage: ./importdbs.sh [-r<dbdump>] [-x<directory_xml>] [-f<path_to_FWD>] [-a<path_to_app.jar>]
Where:
     r = Restore database from dumps in <dbdump> directory (def=/dbdump)
     x = Use the given directory.xml (def=directory.xml) for DB information.
     f = Path to directory containing FWD import.sh (as well as jars p2j.jar, fwd-slf4j.jar) (def=/opt/fwd)
     a = Path to app.jar file containing DDL (def=/opt/hotel/lib/hotel.jar)
NOTE: Any relative paths will be in relation to the location of this script (" './importdbs.sh'")
     t = Test or dry run.

You can also use the legacy ant importdb if the build.properties file is setup correctly.

Start the FWD server

If the directory.xml is already setup, and not database import is necessary, you can use ./server.sh -d to start the server, using port 2080 for debug. You can also use ./start_server.sh to start the server with usage as noted above, to optionally create the configuration and import the database.

Start a ChUI client

Go to deploy/client-chui, and:
  • use ./client-terminal.sh client:cmd-line-option:startup-procedure=helloworld.p to run the native ChUI client
  • use ./client-swing.sh client:cmd-line-option:startup-procedure=helloworld.p to run the ChUI Swing client

For a Web client to work, you need to edit the p2j-entry in directory.xml to point to the 4GL program - in this case, set it to helloworld.p. After this, go to https://localhost:7443/chui, enter your OS credentials and the program will run. Accept the invalid certificate, if needed.

Start a GUI client

Go to deploy/client-gui and use ./client.sh client:cmd-line-option:startup-procedure=helloworld.p to launch the FWD Swing GUI client.

For a Web client to work, you need to edit the p2j-entry in directory.xml to point to the 4GL program - in this case, set it to helloworld.p. After this, go to https://localhost:7443/gui, enter your OS credentials and the program will run. Accept the invalid certificate, if needed.

Debugging a FWD client

For a client started via the command-line scripts, use the -d <port> option to launch the client in debug mode, where <port> is set to your port (like 2998).

For a web client, edit the jvmArgs in directory.xml and add -Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,address=2998,server=y,suspend=n. Keep in mind that this will be used by all spawned clients, including the appserver - if you need to debug web clients, disabled in the scheduler the appserver process launch.

Configuring and Running a Batch Process

Batch Process describes how to setup a batch process account and configure it. This section will describe the steps required for the xfer testcases project.

If you want to commit the changes to the bzr testcases project, copy the non-configured changes from directory.xml to directory.xml.template (i.e. keep the [os-user] and other specific settings).

Configure the Batch Process

These changes are required in directory.xml:
  • add the process account, under security/accounts/processes:
              <node class="process" name="batchtest">
                <node-attribute name="enabled" value="TRUE"/>
                <node-attribute name="description" value="Batch Program Test"/>
                <node-attribute name="master" value="FALSE"/>
                <node-attribute name="server" value="FALSE"/>
                <node-attribute name="alias" value="batchtest"/>
              </node>
    
  • add the clientConfig under /server/default/runtime/:
          <node class="container" name="batchtest">
            <node class="container" name="clientConfig">
              <node class="string" name="cfgOverrides">
                <node-attribute name="value" value="client:mode:batch=true client:driver:background=true client:cmd-line-option:startup-procedure=helloworld.p"/>
              </node>
              <node class="string" name="defaultOsUser">
                <node-attribute name="value" value="{os_user}"/>
              </node>
              <node class="boolean" name="secure">
                <node-attribute name="value" value="TRUE"/>
              </node>
              <node class="string" name="spawner">
                <node-attribute name="value" value="{spawner_path}"/>
              </node>
              <node class="string" name="outputToFile">
                <node-attribute name="value" value="client_batchtest_%pid%_%userid%_%timestamp%.log"/>
              </node>
              <node class="string" name="workingDir">
                <node-attribute name="value" value="{client_start_dir}"/>
              </node>
            </node>
          </node>
    

    where:
    • {os_user} needs to be replaced with the operating system account
    • {spawner_path} with the spawner installation path, usually /opt/spawner/spawn
    • {client_start_dir} with the full path to deploy/client folder
    • note how cfgOverrides contains the program to start, client:cmd-line-option:startup-procedure=helloworld.p
  • save and close directory.xml

Now, generate the certificate and private key using the Cryptography Setup Helper. Go to deploy/server and run this command:

java -classpath ../lib/p2j.jar com.goldencode.p2j.security.SSLCertGenUtil -dir directory.xml --reuse-passwords yes --server-id standard --reuse-ca yes --build-alias-certs batchtest --private-key-password 1\)7Qa\<xE87D\&BeIGbQIhJOS1w7k8U8x\(

You will get an output like this:
Initializing service for directory directory.xml...
Reading company configuration...
Using 'US' for [C] Country Code.
Using 'Alpharetta' for [L] Locality (city, etc).
Using 'GoldenCode' for [O] Organization.
Using 'Hotel' for [OU] Organization Unit.
Using 'GA' for [ST] State or Province Name.
Using 10 years for validity.
Adding account /security/accounts/processes/appserver_process
Adding account /security/accounts/processes/appserver_agent
Adding account /security/accounts/processes/standard
Adding account /security/accounts/processes/batchtest
Adding account /security/accounts/users/bogus
WARNING: alias shared is set for multiple accounts!
Account /security/accounts/users/c5fr73e54xmgt368 ignored - no alias is defined
Account /security/accounts/users/cf0t3kv8944ue2m2 ignored - no alias is defined
Account /security/accounts/users/t1ah3tep134h5v38 ignored - no alias is defined
Account /security/accounts/users/km51oa28xq12h6z7 ignored - no alias is defined
Account /security/accounts/users/y2oc1y9665e0wm5s ignored - no alias is defined
Account /security/accounts/users/77xn6t75wyf6eo79 ignored - no alias is defined
Account /security/accounts/users/k23vt8c5b908fn4t ignored - no alias is defined
Account /security/accounts/users/l7d54u7tmko5825f ignored - no alias is defined
Re-using root CA using [root-ca] alias...
Generating certificate for account with alias [batchtest]...
Private key for alias [batchtest] was encrypted using the [_G9511G4xVMv0_9q_d5HAW(yTSvjpMoi] password and saved in the /security/certificates/private-keys/batchtest node.
Use the access:password:keyentry-batchtest key to set this password in the server's bootstrap config file and delete  the /security/certificates/private-keys/batchtest node from the directory.
Adding certificate for alias [batchtest] to the /security/certificates/peers/batchtest node...
Certificate for alias [batchtest] has checksum [53bd286e13ecf9cfb8213c704ecd9c92]
The private key for certificate [batchtest] was saved in the [batchtest-private-key.store] key store, using store password [_G9511G4xVMv0_9q_d5HAW(yTSvjpMoi] and key-entry password [_G9511G4xVMv0_9q_d5HAW(yTSvjpMoi].
Done.

This output needs to be appended to the deploy/server/pk-store-log.txt, and committed together with directory.xml.template, if needed.

Starting the Batch Process

To start the batch process via the scheduler, add this node under the scheduler - it will start the batch process at FWD server startup:

          <node class="job" name="batchtest">
            <node-attribute name="type" value="process"/>
            <node-attribute name="target" value="batchtest"/>
            <node-attribute name="enabled" value="TRUE"/>
            <node-attribute name="mode" value="now"/>
          </node>

Additionally, you can start the batch process using the ./server.sh -bbatchtest command.

In both cases, the spawner will be used to launch the FWD client associated with the batch process.

Once you run it, you will notice a Hello world! message in the deploy/client/client_batchtest_%pid%_%userid%_%timestamp%.log file.

Running Web tests

By default, directory.xml.template is configured to expose the REST, SOAP and Web handler tests. But, to run these, you need to convert programs which are configured as web services.

The 4GL programs exist in the appsrv/ folder.
  • create the file-cvt-list.txt with the programs in this folder:
    find appsrv -iname "*.p" > file-cvt-list.txt
    echo FwdHandler.cls >> file-cvt-list.txt
    
  • if it does not exist, copy the skeleton project in the root folder of the testcases project (this is how is configured in p2j.cfg.xml)
  • run ant clean convert.list
  • edit src/com/goldencode/testcases/fwd.wsdl and change:
      <wsdl:service name="fwdService">
        <wsdl:port binding="tns:fwdObj" name="fwdObj">
          <wsdl:documentation/>
          <soap:address location="/soap"/>
        </wsdl:port>
        <wsdl:port binding="tns:persistentObj" name="persistentObj">
          <wsdl:documentation/>
          <soap:address location="/soap"/>
        </wsdl:port>
      </wsdl:service>
    

    to:
      <wsdl:service name="fwdService">
        <wsdl:port binding="tns:fwdObj" name="fwdObj">
          <wsdl:documentation/>
          <soap:address location="/wsa/wsafwd"/>
        </wsdl:port>
        <wsdl:port binding="tns:persistentObj" name="persistentObj">
          <wsdl:documentation/>
          <soap:address location="/wsa/wsafwd"/>
        </wsdl:port>
      </wsdl:service>
    
  • run ant jar deployapp.prepare or ant jar deploy.prepare (depending upon using FWD_LIB or co-mingling FWD jars with the application jars)
  • make sure the adminPort in directory.xml is set to 9443 - this is what SoapUI configuration files are using.
  • start the FWD server - go to deploy/server and run ./server.sh -d.
Web tests can be ran via Postman, SoapUI and even the Harness. But, for now, configuration exists only for SoapUI:
  • appsrv/rest/test/fwd-soapui-project.xml is the configuration to run the REST services.
  • appsrv/soap/test/web/fwd-soapui-project.xml and appsrv/soap/test/web/pasoe-fwd-soapui-project.xml are the configurations to run the SOAP services.

Keep in mind that running the pasoe tests requires to set pasoe=true in directory.xml, at the app_server, like this:

        <node class="container" name="appservers">
          <node class="appserver" name="app_server">
            <node-attribute name="pasoe" value="TRUE"/>

Import the XML configuration files in SoapUI and run the tests.

Read More

Running the Client
Windows 11 Virtual Machine Setup with FWD v4 and the Testcase Project


© 2019-2022 Golden Code Development Corporation. ALL RIGHTS RESERVED.