Columns

TestBytes 4.0 from Logic Works Inc.

• By Dan Romanchik
• July 13, 2001

Testing is no fun. Generating test data is really no fun. Even so, the validity of a test often depends on how well your test data matches real-world data. This is certainly true when testing a database application. If the database does not contain appropriate data, there is a good chance that your tests will not really tell you whether or not your application will work right when you put it into production.

POPULAR DATABASES

To populate a database, there are several approaches you can take. One thing you can do is sit someone down at a keyboard and fill records with random data. If you do not have an intern you can assign to this task, it is a good chance your carpal-tunnel syndrome will be aggravated and the data will probably not be all that great. You will have lots of columns with the strings "asdf" and the number "1234" in them.

Another approach is to write a program to populate the database. If you use this approach, your database will have meaningful data, but you will have wasted a good bit of time in the process.

A third approach is to keep copies of old

Standard data profiles in TestBytes 4.0 include first names, last names, street addresses, state abbreviations, company names, phone numbers and several other types of data.

You could also use TestBytes 4.0 from Logic Works Inc., Princeton, N.J. With TestBytes, you can quickly populate databases with many different types of test data, not just random alphanumeric data. One of the ways to do this is to use the standard data profiles included with the package. Standard data profiles in TestBytes 4.0 include first names, last names, street addresses, state abbreviations, company names, phone numbers and several other different types of data commonly found in databases.

CUSTOM PROFILES

If the standard data profiles just do not cut it, you can create your own profiles. For example, one of the databases that I am currently working with uses a five-digit number company code. Using the custom profile dialog box, I quickly defined a new data profile and used the profile to fill up this column.

The new version of TestBytes takes this one step further, though. With TestBytes 4.0 not only can you define the size and type of the test data, you can define data types with multiple segments. My database, for example, has a field which contains E-mail addresses. Since there was no standard data profile for E-mail addresses, I had to create a custom profile.

Again using the custom profile dialogue box, I created a five-segment data pattern. For the first segment, I used the standard profile for first names, the second segment is the character '@,' the third segment is a random alphanumeric field between one and ten characters long, and the fourth segment is a period, or "dot." For the fifth segment, I created a list, with the values "com," "org," and "edu."

The custom profiling feature of TestBytes has a couple of other features which I found useful. First, the dialogue box displays sample data. This lets you verify that the data pattern you set up is actually what you want before you close the dialogue box and populate the database. Second, you can specify the percentage of fields to leave blank.

Once you have defined the data profiles, you can begin to populate the database. You can do this manually, as I did, using the data-generation dialogue box to specify the data profile for each field in a table. If you have many tables, however, you may want to use the multi-table script builder to generate data for multiple tables simultaneously. This feature greatly reduces the amount of time needed to populate a database with data.

RI SUPPORT

An important feature of TestBytes is its support of referential integrity (RI). What this means is that fields linked between two tables will contain common data. In my database, the company code field is found in two of the database's three tables. Once I defined the relationship between the tables, TestBytes knew to populate the column in the child table with data found only in the parent table.

There are several ways to define the parent-child relationships. You can do it manually as I did above, or you can use data models generated by Logic Works' ERwin data-modeling tool. A third way is to let TestBytes use the database under test, assuming that you have implemented referential integrity on the database.

Logic Works ships TestBytes 4.0 on CD-ROM, with a 32-bit version for Windows 95 and Windows NT systems as well as a 16-bit version for Windows 3.1. Installation on my Windows 95 machine was straightforward and quick. It uses the standard Windows 95 setup program and took less than 10 minutes to install. The package also comes with a well-written, spiral-bound user's guide, a nicety that's becoming more and more rare these days. The user's manual even included a section on how to define ODBC data sources under Windows 95.

To run TestBytes 4.0 you need a 486 or Pentium processor, Windows 3.x, Windows 95 or Windows NT, 10 Mb of hard disk space and at least 16 Mb of RAM.