head	1.6;
access;
symbols;
locks; strict;
comment	@% @;


1.6
date	92.12.14.09.30.56;	author gaubert;	state Exp;
branches;
next	1.5;

1.5
date	92.12.14.09.26.48;	author gaubert;	state Exp;
branches;
next	1.4;

1.4
date	92.12.14.06.18.36;	author gaubert;	state Exp;
branches;
next	1.3;

1.3
date	92.12.14.03.11.51;	author lacey;	state Exp;
branches;
next	1.2;

1.2
date	92.12.14.01.31.55;	author gaubert;	state Exp;
branches;
next	1.1;

1.1
date	92.12.14.00.03.09;	author lacey;	state Exp;
branches;
next	;


desc
@@


1.6
log
@*** empty log message ***
@
text
@%
% If your testing specifications were correct, then you can
% include the text for the test data description and expected 	
% results. Otherwise, incorporate the corrected descriptions.
%
%-------------------------- writefile ------------------------------------
\subsection{Testing Procedure for Module writefile}

\begin{description}

\item[{\bf Test Data:}]

The first test case for this routine evolved printing the output tasks
to the screen. This ensured that the task are being formatted correctly.
The next test case will store the tasks to the file. Each of
the entities of the task list was checked for format and
completeness. This test case was done several times with different
test data so that a broad range of output files are created. The last
test consisted of creating a task file, and then reading that same
file to make sure that the the file-read is the same as that which was written.

\item[{Expected Results:}]

The expected results for the first case included all of the tasks
formatted for the screen and in the same order as they were stored
into the list. The second case involved the same results as the first,
however the output will be in the file. The last case wrote the file
in the same way that it reads it from the parser. The task was
correctly filled into the database after the readfile routines have
been processed.

\item[{Actual Results: }]

For the first test, the task was printed to the screen in the
correct format. In the second case, the tasks were stored to the file.
The tasks were stored correctly in the file. Then this file was read
in from the readfile routines. The results of this test were positive.
The readfile routines were able to read from the output of the
writefile routines.

\end{description}

%-------------------------- yyparse ----------------------------------
\subsubsection{Module yyparse}

\begin{description}

\item[{\bf Test Data:}] 

The test case data consisted of a test file. The files
that was used contained a task that does not parse correctly,
meaning that the syntax is wrong. This will be considered as case one.
Case two involved testing the stack that is used between the
scanner and the parser. This stack contained all of the information
that will be placed in to the database but will not be in the correct
order. After the parser is finished with the file and it has
correctly been parsed the stub functions were printed out from the contents
of the stack to the screen. 


\item[{Expected Results:}]

  The expected results for case one contained an error printed to the
screen, and the number that correlates to the error was to be displayed.
A number of ``0'' constituted a correct parse. A number of ``1''
constituted a parse that is incorrect. The file has syntactic
errors at this point. The results for the case two test was to be the
correct integers and strings in the stack that have come from the
file. The stack contents were listed when the parser has parsed the
file. The contents of the stacks, whether string or integer, came
from the input file. All of the tokens that describe the task, the
"name", "date", etc. was not listed here. Only the value after the
"name" or "date" etc. was listed. 

\item[{Actual Results: }]

From the test files used, if the file was a bad file, the parser
recognized that and returned a one to the caller of yyparse. A good
parse was recognized by a zero from the caller. The testing of this
function required that the information from the files got into the
internal database. Thus, the database was printed out to show the
contents. This data was compared to the data in the file and was correct.
There were no subtasks to check, so this information was not printed.
The subtask information is incorporated into the grammar for the next
version. 

\end{description}

%----------------------------- yylex ------------------------------------
\subsubsection{Module yylex}

\begin{description}

\item[{\bf Test Data:}]

 The test data for this function consisted of a file that displays
all of the symbols, keywords, strings, and integers that an input file
can have for the scanner. The cases consisted of making a number
of files that test all of the keywords, strings, integers, and symbols
can be encountered in scanning.


\item[{Expected Results:}]

The expected results displayed the correct token code numbers for
the keywords, symbols, strings, and integers from within the file to
the screen.

\item[{Actual Results: }]

The correct tokens for the information that was contained in the file
were displayed to the screen, and the strings were put correctly into
the string table.

\end{description}

%------------------------------- readfile ----------------------------------
\subsubsection{Module Readfile}

\begin{description}

\item[{\bf Test Data:}]

Data that will be used to test the readfile module was made up
of the following cases. Case one was sent to the readfile routine
the filename of a file that exists. Case two sent the
routine a filename of a file that does not exist. Case three 
conducted a call to the function yyparse as many times necessary to
fulfill all of the error conditions that happened. 

\item[{Expected Results:}]

  For case one of the testing procedure for the readfile
module, the expected result was that the file was opened
successfully. Case two's results was to display a message that the
file doesn't exist. Case three was in the form of a
while loop where all of the error cases was be
displayed to the screen.

\item[{Actual Results: }]

If there was not a problem with the file and it was in the format
specified by the scanner and parser then the file was successfully
opened and used. If this was not the case, then a one was returned to
the caller.

\end{description}


@


1.5
log
@*** empty log message ***
@
text
@d118 1
a118 1
\subsubsubsection{Module Readfile}
@


1.4
log
@*** empty log message ***
@
text
@d7 1
a7 1
\subsection{Module writefile}
d29 1
a29 1
correctly filled into the database after the read-file routines have
d44 1
a44 1
\subsection{Module yyparse}
d90 1
a90 1
\subsection{Module yylex}
d118 1
a118 1
\subsubsection{Module Readfile}
d124 2
a125 2
Data that will be used to test the read-file module was made up
of the following cases. Case one was sent to the read-file routine
d133 1
a133 1
  For case one of the testing procedure for the read-file
@


1.3
log
@*** empty log message ***
@
text
@d13 2
a14 2
The first test case for this routine will involve printing the output tasks
to the screen. This will ensure that the task are being formatted correctly.
d16 2
a17 2
the entities of the task list will be checked for format and
completeness. This test case will be done several times with different
d19 1
a19 1
test will consist of creating a task file, and then reading that same
d24 5
a28 5
The expected results for the first case will include all of the tasks
formatted for the screen and in the same order as they were stored into the
list. The second case will involve the same results as the
first, however the output will be in the file. The last case will
write the file in the same way that it reads it. The task will be
d34 1
a34 1
For the first test, the tasks were printed to the screen in the
d50 2
a51 2
The test case data will primarily consist of a test file. The files
that will be used will contain a task that does not parse correctly,
d53 2
a54 2
Case two will involve testing the stack that is used between the
scanner and the parser. This stack will contain all of the information
d57 2
a58 7
correctly been parsed the stub functions will print out the contents
of the stack to the screen.  Case three will have a tasks that contain
subtasks. These subtasks will have subtasks.  In this case the tasks
and subtasks will be displayed to the screen when the whole task is
parsed by the parser. These subtasks and tasks will be in the same
format as the format for the call to the database functions. This will
allow the convergence to be a little easier.
d63 5
a67 5
  The expected results for case one will contain an error to the
screen, and the number that correlates to the error will be displayed.
A number of ``0'' will constitute a correct parse. A number of ``1''
will constitute a parse that is incorrect. The file has syntactic
errors at this point. The results for the case two test will be the
d69 2
a70 2
file. The stack contents will be listed when the parser has parsed the
file. The contents of the stacks, whether string or integer, will come
d72 2
a73 8
"name", "date", etc. will not be listed here. Only the value after the
"name" or "date" etc. will be listed. The results for the third case
will come at the end of each main task that is completely parsed. Here
the contents of the task list stack will be printed out to the screen.
If there is a task that does not have any subtask, then that task node
will be the first element on the stack. If the task should have
subtask in the task list, all of the subtasks will be printed before
the main task is printed.
d96 1
a96 1
 The test data for this function will consist of a file that displays
d98 1
a98 1
can have for the scanner. The cases will consist of making a number
d105 1
a105 1
The expected results will display the correct token code numbers for
d124 6
a129 6
Data that will be used to test the read-file module will be made up
of the following cases. Case one will be to send the read-file routine
the filename of a file that exists. Case two will be to send the
routine a filename of a file that does not exist. Case three will be
conducted to call the function yyparse as many times necessary to
fulfill all of the error conditions that can happen. 
d134 4
a137 4
module, the expected result will be that the file was opened
successfully. Case two's results will display a message that the
file doesn't exist. Case three will be in the form of a
while loop where all of the error cases will be
@


1.2
log
@*** empty log message ***
@
text
@a0 1
\subsection{File Read/Write Module}
a5 2
\begin{description}

d46 2
d103 2
d126 2
d129 1
a129 1
\subsection{Module readfile}
d131 2
d159 1
@


1.1
log
@Initial revision
@
text
@d8 36
a43 3
\item[{Test Data: }] 
\item[{Expected Results: }]
\item[{Actual Results: }] 
d45 110
@
