ApTest Manager documentation: CLI: importTests

importTests

NAME

importTests - import tests into ApTest Manager

SYNOPSIS

importTests [-F] [-d dir] [-c] suite fieldFile csvFile

DESCRIPTION

importTests allows the import of qualified records from a CSV file into an existing ATM test suite. These records are extracted from the CSV file, transformed via the rules in a mapping file, and then saved as ATM test cases. Any records that do not match the requirements in the mapping file are ignored, and a warning is issued.

OPTIONS AND ARGUMENTS

-F
Force overwriting of existing test cases.
-d dir
Put the tests into directory dir (relative to the test suite top). By default, all tests extracted are placed in the top level directory of the test suite.
-c
Collapse multiple records that are missing an "ID" field into each other, so that field contents that span rows will be merged together into the record in the ATM test case.
-n
Don't really generate the test cases, just say what would have been done.
suite
The test suite to import into.
fieldFile
A file containing mappings from input fields to fields in the test suite.
csvFile
The input file (the first line of which must be the field names).

FIELD FILE

The field mapping file must contain at least the following fields:

SOURCE
The name of a column in the source CSV file (note that field is NOT required to exist in the CSV file, so you can use it as a dummy to populate things in your ApTest Manager Test Cases that were not in the original input - like the creation date in the example below).
TARGET
The name of a field in the target suite's schema.
REQRD
A field indicating whether the field is REQUIRED to be present or not in the input data.
DEFAULT
A field indicating the value to put into a field if it is NOT required in the source data and is blank.
PATTERN
An optional perl substitution pattern that will be applied to the input before placing it into the new test case.

An example mapping file might look like:

SOURCE  TARGET       REQRD DEFAULT    PATTERN
name    ID           Y
input   Input        N     None
process Procedure    Y
purpose Requirements Y
CDATE   CDATE        N     2005/12/01

CVS FILE

The CSV file MUST have as its first line the label for each column, so that the rest of the file can be analyzed in that context. Also, there MUST be an ID field, and that field MUST map into a field in the CSV file that contains something that, perhaps via a pattern, can be mapped into zero or more folder names and a test case name. The code as distributed assumes that the test case name is just digits, and that anything before the digits and a optional ".", "_", or "-" represents a folder name to use. If there are slashes ("/") in the ID field, those are used as components of the folder name automatically. The following IDs would be mapped into the following test case names:

CSV                    Field Value
foo-123                foo.dir/123.bts
cmpnt/feat/123         cmpnt.dir/feat.dir/123.bts
cmpnt name - feat123   cmpnt_name.dir/_feat.dir/123.bts

Feel free to modify these rules. You can find them in this script after the line that says "UPDATE THE TEST NAME PATTERN HERE".

ApTest manager recognizes two forms of dates in the creation date field of a test case... seconds since the epoch (a Perl concept, and returned by the Perl function "time"), and numeric dates in the form YYYY/MM/DD. It is possible to use the PATTERN field to transform your date format into ApTest Manager's date format. For example, if a CSV file has a value like MM/DD/YYYY (fairly typical in the United States), the following would work:

SOURCE TARGET REQRD DEFAULT    PATTERN
CDATE  CDATE  N     2004/07/04 "~s{(.*?)/(.*?)/(.*?)}{$3/$1/$2}"

Finally, remember that the input file for this is a CSV file. CSV files are a Windows/DOS file format, and consequently are expected to have lines ending in CRNL, not solely NL as on UNIX systems, or solely CR as on Mac systems. If your copy of ATM is hosted on a UNIX system, and you are generating CSV files on Windows platforms, be certain to transfer the files to the UNIX system in "binary" mode, not in "text" or "ascii" mode. That way the line endings will be preserved, and this script will perform as expected.

Copyright © 2000-2006 Applied Testing and Technology, Inc. All rights reserved.