Code Tester for Oracle 4.1 - Installation Guide

About this Guide

This guide describes how to install and use Code Tester for Oracle® administrative features.

Additional Information

In addition to this guide, there are a number of options available for quickly finding the information you need.

Online Help

There are several ways to access online help topics.

Release Notes

To access the latest release notes, go to:

support.quest.com/technical-documentation

About Code Tester for Oracle

Code Tester for Oracle automates the process of testing PL/SQL programs, making it possible for you to identify bugs and verify program correctness in a fraction of the time it has taken previously. Rather than write (and maintain) thousands of lines of test code, PL/SQL programmers describe the expected behavior of their programs through a graphical interface. Code Tester then generates the required test code, and runs it whenever you reCode Tester (either through the interface or via command line execution).

The following provides a summary of how Code Tester works:

• You describe the expected behavior of your program through the Test Builder interface. In some cases, you will provide some customization logic, but for the most part, you simply point and click.
• Code Tester stores your test definitions in a repository (Oracle backend) so that you can easily manage them over time. This same repository also provides a means of documenting and analyzing the state of your code testing.
• Code Tester generates a PL/SQL package that implements the tests you have described, automatically incorporating any customization logic you have provided.
• You run your test as needed (usually after each change you make to the program and in overnight builds) with the press of a button from the Test Dashboard. Code Tester performs all required initialization and clean up.
• Code Tester automatically verifies the results and displays them in an intuitive “red-light, green-light” Results Viewer.
• Create back ups of your test definitions and share them among developers and application groups through the import/export facility.

System Requirements

Before installing Code Tester for Oracle, ensure your system meets the minimum hardware and software requirements that are listed in the Code Tester for Oracle Release Notes that accompany this release.

Repository Placement and Access Options

Code Tester for Oracle uses a backend repository to store tests and testing results. Each database being tested must have its own repository.

When you install Code Tester, you must specify the Oracle schema into which the test repository will be placed. This repository (a set of tables) holds the definitions of the tests for your programs. This schema can be created specifically for the Code Tester repository, or those tables can be placed in an existing schema.

Before you install Code Tester, you should decide where the repository and the test code generated by Code Tester will be placed, in relation to the code being tested.

This section reviews the most common configurations and offers advice about how to install and use Code Tester to match those configurations. In each configuration we explain how to use Code Tester in these three different types of schemas:

Installation Options

You can install and use Code Tester in each of the following configurations.

• Shared repository
• Private repository
• Shared repository, Code Schema = Test Schema
• Single, shared test schema for all developers
• Separate test schema for each application

Installing a Shared Repository

There are two ways to create a shared repository:

• Public Synonyms
• Private Synonyms

Public Synonyms

Choose the "Create public synonyms..." option in the Installer.

Code Tester will then create public synonyms for the repository so that it can be accessed from any other schema in that database instance.

Private Synonyms

In Code Tester the Installer does not automatically create private synonyms. You must create them by running scripts manually in SQL*Plus or Toad or another execution environment.

When you install Code Tester, do not check the "Create public synonyms..." option. Instead, install the repository into the specified schema without public synonyms. After the installation is complete, open your SQL execution environment and connect to the Code Tester schema. You will then run two scripts, each of which are located in the Code subdirectory of Code Tester's installation folder:

qu_grant_execute.sql: When running this SQL*Plus compatible script, you specify the name of the Test Schema from which you want to run Code Tester. The EXECUTE privilege is then granted to you schema for all Code Tester objects.

After running this script for each of the schemas from which you want to run Code Tester, you will need to connect to each of these schemas in turn and run the following script:

qu_private_synonyms.sql: When running this SQL*Plus compatible script, you specify the name of the Code Tester Schema (owner of the repository). Private synonyms are then created for all relevant Code Tester objects.

Code Tester can now be used from each of these individual Test Schemas.

Installing a Private Repository

This is the simplest installation. The schema in which the repository is installed is also the test schema and the code schema. You simply install Code Tester into the application code schema. The repository of test information is private to this schema and cannot be seen, used, or run by any other schema.

Good for: Small projects, evaluating Code Tester

How to do this: Install, but do not install public synonyms during the install and do not install any private synonyms afterwards.

To use Code Tester: Connect to the schema in which Code Tester was installed (and which also contains your code or has execute authority on the code you want to test).

Advantages

You don't need any special privileges to install the product (as long as your code schema has the privileges to create procedures, tables, etc.).

Disadvantages

• The repository is not shared, so other members of your development team cannot see, change or run your test definitions.
• Multiple, private repositories consume more database resources.
• Lots of different kinds of code (source code, test code, Code Tester repository) are all mixed in together, making it hard to manage your code base.

Installing a Shared Repository, Code Schema = Test Schema

You install Code Tester into its own schema and make the repository and test engine available to the various Code Schema through public or private synonyms. You run Code Tester from the Code Schema (owns the application code). In other words, the Test Schema is the same as the Code Schema.

Good for: Team development, in which test definitions need to be shared.

How to do this: Install with public synonyms or create private synonyms after installation is finished.

To use Code Tester: Connect to your Code Schema and choose the programs in (or accessible from) that schema.

Advantages

• All test definitions are stored in a single, shared repository.

• You don't have to set up a separate Test Schema from which testing is performed.

Disadvantages

• You need to be able to connect to a schema that creates a new user in Oracle.
• Need ability to create public synonyms (if that approach is chosen)
• All test objects are defined in the Code Schema to which they apply. Test objects are, therefore, mixed in with application code, which can be confusing.

Installing a Single Shared Test Schema for all Developers Repository

In this configuration, you take the extra step of creating a schema in which test code will be created for all applications on which members of the team are working.

Code Tester does not create the Test Schema. You will need to do this yourself outside of the Code Tester install, but it does not have to be created before you install Code Tester.

Good for: Team development, in which the same team works on several different applications.

How to do this: Install with public or private synonyms, depending on whether you want the repository to be available to all schemas or a selected subset. Click here for more details.

To use Code Tester: Connect to the shared Test Schema and choose the programs to test from the relevant Code Schema.

Advantages

• All test definitions are stored in a single, shared repository.
• Test objects are kept separate from application code
• Developers can easily move between test definitions of various applications

Disadvantages

• Test code for multiple applications are mixed together, which can make it difficult to keep test code distinct and manageable in the Dashboard.

Installing a Separate Test Schema for Each Application Repository

In this configuration, you take the extra step of creating a separate schema in which test code will be created for each application on which members of the team are working.

Code Tester does not create the Test Schemas. You will need to do this yourself outside of the Code Tester install, but it does not have to be created before you install Code Tester.

Good for: Team development, in which different members of the team work on different applications or subsystems.

How to do this: Install with public or private synonyms, depending on whether you want the repository to be available to all schemas or a selected subset.

To use Code Tester: Connect to the Test Schema for your application and choose the programs to test from the relevant Code Schema.

Advantages

• All test definitions are stored in a single, shared repository.
• Test objects are kept separate from application code
• Developers working on one application cannot see or run tests for another application.

Disadvantages

• Must create the largest number of new schemas (for three applications, you will have one Code Tester Schema and three Test Schemas). This results in more management effort and more database resources devoted to the schemas.