Go to the previous, next section.

"ls -lR" Getter

@everyfooting Author: Dhinesh // Editor: Dhinesh // Texinfo: Dhinesh @| @|3 December 1994

This chapter shows how to test the ls -lR getter module in the free archie server.The testing of this module is very important because it plays a vital role in the functioning of the server. It gives the update of the list of the files in the each of the ftp sites showing up in the database. It makes an update of that information for every site periodically.

Testing "ls -lR getter

To verify that the ls -lR getter is able to obtain the ls -lR listings of the ftp-sites, we can just add a few ftp-sites to the ftp-site list database and then activate this module to act upon those site names. The resultant listings of those sites will be written to the temp file in the module. Now we have to confirm that the listing collected by the module is the same as the original,complete and the update collection of the ftp-site file list. This can be done by doing ftp to each of those sites and issuing a ls -lR command at each site. Now , these listings can be compared with those collected by the module.When there is no difference in the two listings for each of the ftp-sites, it means that the module is performing the getter job for the database.

We also have to verify how the module's performance for all possible conditions although those may occur very rarely.

Testing with site -information in the database being old

Initially we shall set the AGE field in the include file to 1. Let us test this situation on a few ftp sites for which we have access to change the directory information. Now the module has to be executed to get the listing of the ftp-sites in the database.After it has been done , the directory and the filenames have to be modified in the listed ftp-sites. We do this to distinguish between the listing of the previous day and the next day.According to the implementation, the module has to see the AGE of the ftp-site listing in the database and if it is found to have expired, the module should obtain a new listing afresh from the corresponding ftp-site. Since we are assuming to have made a few changes in the directory information of the ftp-site, the module should have updated the changes inthe database. If it is done successfully, it confirms that the module does the updation of the "ls -lR" listings of the ftp-sites once it has expired.

Testing when a new ftp-site is being added to the ftp-site list.

When a new ftp-site is added to the ftp-site list, it obviously will not have a ls -lR listing in the database. Hence, the module has to care of this condition and do a ftp the that site, issue an "ls -lR" command at the site and obtain and store the information in the database. This can be tested by adding a new ftp-site to the existing site-list database and executing the module.

Testing the case of executing the module on a ftp-site list name which is non-existant.

Suppose that a new entry is made in the ftp-site list database which actually does ot represent any site at all. The test module will try to access the ftp-site with that name, will find that it is non-existant and report an error to the user that the site-list has an entry for which there is no actual site available and should terminate the execution.

What if the "ls -lR" getter is not able to connect to the ftp-site?

Some-times it may happen that the ftp-site might be existing but still the module will be not able to connect to it. In such cases the module should keep on trying for certain period of time and then stop it, indicating the diagnostics to the user.It has to be made sure that the module does not get locked up in trying to connect to the remote ftp-site but returns control to the server after a specified period of time.

@everyheading @thischapter @|@|Indices @thispage @everyfooting

Go to the previous, next section.