Testbeds were used in the creation of the YEdit system for testing changes and new ideas. The testbed web servers were fully functional web servers that were placed on local machines to test the responses of the system. The reason for using local testbed web servers was to test ideas and changes in a fully working environment before they were run live on the public web server.
Some of the reasons for creating a testbed were to test out ideas and changes, to get a working model, to test the feasibility of concepts and to see what other people think of the ideas. Also it allows a small number of people to test and refine new ideas before they are moved to the public web server.
The testbeds were created so that system could be plugged into a web server, and it could be tested and re-written as the process continued around the iterative spiral of ideas, design through testing. Because of the development path suggested by the spiral model, the ideas, design, coding, testing, etc are all spread throughout the whole project. This means that it is important to have testbeds where the changes and new ideas can be tested and refined before they are finalised for the public web server. Effectively this means that the project has been through many phases of idea generation, design, coding and testing. Because of this various different approaches have been tried for many different parts of the project. For example, some of the early prototypes had options and directory structures hard coded into the code (as they were only there for testing ideas), and as the ideas worked, the options and directory structures were moved out to a initialisation file, in progressive steps. In the current version all the directory structures are stored in the initialisation file, along with many other options, such as method of access to the version storage area, and the classes used to access it.
The initialisation file has been further extended to generalise the features. The current version supported accessing various initialisation files, for example there may be one per person, one per application, along with ones for the system as a whole, and custom settings based on both the person and the application. This generalisation would allow the initialisation files to be used in a more general context, as well as supporting both web and non-web access to the versioning storage area.
As an example, here is a portion of the initialisation file. This is the portion that defines where the file storage, that stores the versions, is located. As can be seen in the file (Figure 8: Example portion of an initialisation file), it can store information for more than one system, which allows the same initialisation file to be used on different systems with ease. The information about the storage location is supplied with the "Collaboration.storage" option; this allows the choice of system that the engine is currently running on. The options for this particular file are "File.YEdit" for running on the public web server or "File.localhost" for running on one of the local test web servers. As can be seen by the options below that, the option for "Collaboration.storage" is then used to select the correct file locations and code to access that location. A full example of an initialisation file is located in the appendix - Appendix A: A full example of a preference file.
##---Program wide Preferences (properties)--- ##Location = Jar:/Preference/ ##Default systems for the storage location Collaboration.storage = File.YEdit ##File system storage Collaboration.File.localhost.BaseServer = D Collaboration.File.localhost.BaseDir = \\Software\\Java\\revisions\\ Collaboration.File.YEdit.BaseDir = /usr/home/yedit/revisions/ FactoryAccess.File.localhost = com.YEdit.ServerInterface.FileSystem.FileSystem FactoryAccess.File.YEdit = com.YEdit.ServerInterface.FileSystem.FileSystem
Figure 8: Example portion of an initialisation file
The main project webserver was accessible worldwide. The local testbeds were used to test changes and ideas before they are put onto the public server. The local testbeds are especially useful for tests that would not be advisable to run over the Internet. These are tests like loading response (testing what happens under heavy load), and any other tests that may interfere with either the other hosts on the same machine as YEdit, or the machines in-between the two systems being tested.
| Previous: | 4.14 Testing |
| Next: | 4.16 Summary |