Go to the previous, next section.
@everyfooting Author: ensley // Editor: ensley // Texinfo: ensley @| @| 3 December 1994
Since Free Archie was built to be very modular it is easy to test each
module separately and completely. For this module we can see the big
picture as input coming from the user and the output is the data sent
to the queuer through the named pipe.
The input to the telnet-interface is through standard in from a remote
user through a telnet connection. Each string read in is parsed and
a corresponding function is called depending on the first "word" in
the input. This testing is covered in the functional testing section.
At this level, the reading from the standard in must be tested
for EOF and strange characters dealing with terminal types.
The output for this module is a search "packet" consisting of 6 items:
type, nhits, string, id, verbosity, and niceness (see Implementation
Manual for more detailed info). The "type" field is an integer
defined in "~server/src/include/search-types.h". All of the
interfaces, the queuer, and the searcher rely on this file to be
correctly updated. Each module has no way of knowing if these
defines are correct. But keeping the defines in one file will
minimize problems throughout modules however. The rest of the items
in the packet will be checked for appropriate values before sending
them to the queuer. The queuer will also check for valid input in
case maintenance at a later time will change the interfacing between
modules and create an inconsistency between them. The output is easy
to test for correctness because the result is an ascii file. It can
be cat'd while interactively entering commands to the interface.
Each command accepted by the telnet-interface has a corresponding function.
As discussed in the Implementation Manual, the functions will have one
argument or none. If the function sets an environment variable, the
variable that gets set has a known range (from implementation manual)
so that a check can be done before it is set. All results of the
commands can be seen if a variable list dump was done. Perhaps adding
a debug option that lists all variables and their values and puts them
into a log file would be useful. Every command can be tested
thoroughly (bounds,fault tolerant) by running the program and watching
the log file.
Go to the previous, next section.