Browse Prior Art Database

Generation of Mock Scripts for Unit Testing Other Scripts Disclosure Number: IPCOM000132104D
Original Publication Date: 2005-Dec-01
Included in the Prior Art Database: 2005-Dec-01
Document File: 3 page(s) / 30K

Publishing Venue



This article proposes a simplification in the activity of unit testing shell scripts that interact with complex environments where several other scripts are invoked as part of the shell script subject to test. Whereas there are several well described approaches for unit testing source code for programmatic languages, the unit testing of shell scripts is often relegated to a second plan. Typically, shell scripts are used in support of deployment and administration of large solutions and the verification of their integrity is often overlooked during the development phase of a project in favor of the verification of the runtime logic implemented in some higher level language, such as C++, .Net or Java. A new technique is required because the cpst of verifying the integrity of a shell script often prevents proper validation. The alternative today is to successively execute the shell script under development and attempt to modify the behavior of the underlying development environment to exercise the script paths.

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

Page 1 of 3

Generation of Mock Scripts for Unit Testing Other Scripts

The core idea is to introduce a shell script development framework where the invocation of other shell scripts is intercepted and used to produce mock shell scripts with some basic behavior that can later be customized to fully meet the expectations of the shell script under development.

The advantages over the current alternative are
1. higher quality for the developed shell scripts, since the mock shell scripts allow for a much wider range of responses to the calling script.
2. reduced development time, since the mock shell scripts will always execute in a fraction of the time required to execute the actuall scripts in the development environment

As an example, while developing a shell script that deploys an application into the WebSphere environment, there are several WebSphere scripts that must be invoked and they often take several minutes each to execute. The proper validation of the shell script under developlement should account for
(1) whether the WebSphere script has actually been invoked when it should, (2) whether the WebSphere scripts have received the correct parameters, and (3) whether they returned the proper error code. The entire validation process of the shell script under development would require (1) the deployment of the actual WebSphere environment on each machine where verification is required, and (2) several runs to validate different scripting paths.

It is clear that such development methodology is inefficient and can be replaced by a methodology where most of the development of the shell script is performed on top of a lighterweight environment followed by fewer runs on top of the actual heavyweight environment.

This article proposes a shell script development framework where the shell script under development is initially invoked by a virtual shell that will detect the invocation of other shell scripts.

As an example of the target end result, consider the following input script:

Script example (buildSamples.bat)


REM Arguments
REM <WAS_HOME> The directory for the WebSphere Application Server

REM where CEI has been installed
REM ----------------------------------------------------------------------------

REM Exit error codes:
REM 0 = Success
REM 2 = Invalid WAS_HOME
REM 3 = Compilation failed


if (%1)==() GOTO NO_WAS_HOME
set WAS_CEI_HOME=%~1
set CEI_HOME=%~dp0..

set WAS_CEI_HOME_SETUP_CMD=%WAS_CEI_HOME%\bin\setupCmdLine.bat

set LOCAL_CLASSPATH=%LOCAL_CLASSPATH%;%CEI_HOME%\lib\events-consumer.jar
set LOCAL_CLASSPATH=%LOCAL_CLASSPATH%;%CEI_HOME%\lib\events-client.jar


Page 2 of 3

set LOCAL_...