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


1.4
date	92.11.11.10.50.59;	author lacey;	state Exp;
branches;
next	1.3;

1.3
date	92.11.11.01.51.07;	author gaubert;	state Exp;
branches;
next	1.2;

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

1.1
date	92.11.10.00.08.11;	author gaubert;	state Exp;
branches;
next	;


desc
@This is the testing spec for the function yyparse
@


1.4
log
@*** empty log message ***
@
text
@
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% The following subsubsection should be repeated for each module that
% is invoked by the top-level module.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsubsection{Unit tests for function yyparse} 
\begin{description}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Describe the test for the module.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\item[{\bf Description of test for function yyparse:}] \hfill \\
  Since the function yyparse needs yylex for it to work properly,
yylex must be completely tested before this stage of testing happens.
The function yyparse will be tested by an input file and the printout
of the rules that define the grammar of the input file. Also, a stack
that contains the information stored for the current task that is
being read will be tested. This stack is made from the scanner and the
parser. The stack that contains the subtasks and the task themselves
will be printed to the screen once the whole task has been parsed.
This process will be done for all of the task in the file.



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Use of stubs or other software to facilitate the test
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\item[{\bf Overhead software description:}] \hfill \\
  The overhead software to test the yyparse function will consist of a
function to print out the contents of the both stacks, the stack that
contains the information for the parse and the stack that holds the
information for the task list.




%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% What data did you use to conduct the tests?
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\item[{\bf Test case data:}] \hfill \\
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,
meaning that the syntax is wrong. This will be considered as case one.
Case two will involve testing the stack that is used between the
scanner and the parser. This stack will contain 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 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.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Briefly, what type of results do you expect?
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\item[{Expected Results:}] \hfill \\
  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 correct integers and strings in the stack that have come from the 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 from the input file. All of the tokens that describe the task, the "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.



\end{description}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% DO NOT FILL OUT THE FOLLOWING SECTION FOR THE TESTING SPEC DELIVERABLE!!
% The testing results will be turned when the practice demo is given.
%
% For each top level module, describe the testing results.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 
%\subsubsection{Actual Test Results}
@


1.3
log
@This is the latest revisions on typos on theis deiting process, and I am just talking out of my ass
@
text
@d15 1
a15 1
yylex must be completely tested before this stage of testing happends.
d18 5
a22 5
that contains the information stored for the current task being read.
This stack is made from the scanner and the parser. The stack that
contains the subtasks and the task themselves will be printed to the
screen once the whole task has been parsed. This process will be done
for all of the task in the file.
d42 1
a42 1
The test case data will primararly consist of a test file. The files
d45 1
a45 1
Case two will envolve testing the stack that is used between the
d48 1
a48 1
order. After the parser is finnished with the file and it has
d55 1
a55 1
allow the convergence a little easier.
d63 1
a63 1
screen, and the number that coorolates to the error will be displayed.
d65 1
a65 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 correct integers and strings in the stack that have come from the 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 from the input file. All of the tokens that describe the task, the "name", "date", etc. will not be listed here. Only the value after the "name" or "date" etc. will be listed. The reults 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.
@


1.2
log
@This is rhwefvdsmklvfd;vbjkglfd;hjfrykl;h
@
text
@d18 1
a18 1
that contains the information stored for the strings and the integers.
d42 1
a42 1
The test case data will primararly consist of the test file. The files
d61 1
a61 1
\item[{Expected Results:}] \hfill \
@


1.1
log
@Initial revision
@
text
@d1 1
@
