Establishing a Test Environment This section describes how to design a test data structure and how to fill tables with test data. Designing a Test Data StructureWhen you test an application that accesses DB2 data, you should have DB2 data available for testing. To do this, you can create test tables and views. For information on the DDL to create tables and views, refer to Chapter 2. Test Views of Existing TablesIf your application does not change a set of DB2 data and the data exists in one or more production-level tables, you might consider using a view of existing tables. To create a test table, you need a database and tablespace. Normally, a database administrator (DBA) can make sure that a database and tablespaces are available for your use. If the data that you want to change already exists in a table, consider using the LIKE clause of CREATE TABLE. If you want others besides yourself to have ownership of a table for test purposes, you can specify a secondary ID as the owner of the table. For information about ownership and privileges, refer to Chapter 2. If your location has a separate DB2 system for testing, you can create the test tables and views on the test system, then test your program thoroughly on that system. This chapter assumes that you do all testing on a separate system and that the person who created the test tables and views has an authorization ID of TEST. The table names are TEST.EMP, TEST.PROJ, and TEST.DEPT. Analyzing Application Data NeedsTo design test tables and views, first analyze your application's data needs.
Create a test table on your list when either:
To continue the example, create these test tables:
To support the example, create a test view of the DSN8710.DEPT table. Because the application does not change any data in the DSN8710.DEPT table, you can base the view on the table itself (rather than on a test table). However, it is safer to have a complete set of test tables and to test the program thoroughly using only test data. The TEST.DEPT view has the following format:
Obtaining AuthorizationBefore you can create a table, you need to be authorized to create tables and to use the tablespace in which the table is to reside. You must also have authority to bind and run programs you want to test. Your DBA can grant you the authorization needed to create and access tables and to bind and run programs. If you intend to use existing tables and views (either directly or as the basis for a view), you need privileges to access those tables and views. Your DBA can grant those privileges. To create a view, you must have authorization for each table and view on which you base the view. You then have the same privileges over the view that you have over the tables and views on which you based the view. Before trying the examples, have your DBA grant you the privileges to create new tables and views and to access existing tables. Obtain the names of tables and views you are authorized to access (as well as the privileges you have for each table) from your DBA. Creating a Comprehensive Test StructureThe following SQL statements shows how to create a complete test structure to contain a small table named SPUFINUM. The test structure consists of
For details about each CREATE statement, refer to Chapter 2. Filling the Tables with Test DataThere are several ways in which you can put test data into a table:
Testing SQL Statements Using SPUFIYou can use SPUFI (an interface between ISPF and DB2) to test SQL statements in a TSO/ISPF environment. With SPUFI panels, you can put SQL statements into a dataset that DB2 subsequently executes. The SPUFI main panel has several functions that permit you to
SQL statements executed under SPUFI operate on actual tables (in this case, the tables you have created for testing). Consequently, before you access DB2 data,
|
Team-Fly |
Top |