Browse Prior Art Database

An inexpensive way to test a command line interface

IP.com Disclosure Number: IPCOM000021821D
Original Publication Date: 2004-Feb-10
Included in the Prior Art Database: 2004-Feb-10
Document File: 2 page(s) / 53K

Publishing Venue

IBM

Abstract

An inexpensive way to test a command line interface

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 2

An inexpensive way to test a command line interface

The problem

In an event driven storage subsystem environment, a set of command line tools are developed which allows the customer to perform configuration tasks on the subsystems. These tools' main functionality includes validating various input parameters, and constructing events and sending them to the subsystems to carry out the actions. These tools need to be tested just like any other programs. Generally a test involves executing the tools on a fully working system. Inevitably this would result in the subsystem carrying out the actual actions. While this is necessary at later stage of development, it is rather expensive at the early stage because:

1) the subsystem itself may not be fully developed when the command line tools are available, and it is therefore impossible to fully test some of the commands. Meanwhile the developers for the subsystem itself may require fully working command line tools to perform their unit tests. This is a chicken or egg situation.
2) the command line tools may perform actions that require certain resources to be present in the subsystem. For example, in a storage system, to delete a virtual disk it must exist in the first place. But this may not be necessary at the early stage of development; we may simply want to unit test the command's good and bad path code.

The benefits

The idea is to bypass the subsystem completely so that during the early stages of development it is possible to test the command line tools independently. The advantages are:
a) the development of the tools and the subsystem no longer depend on each

other.


b) it speeds up the testing of the tools. Some actions may take a long time to complete (e.g. migrating data between different virtual disks). Bypassing the subsystem allows these co...