diff options
Diffstat (limited to 'TAO/orbsvcs/tests/Simple_Naming/README')
| -rw-r--r-- | TAO/orbsvcs/tests/Simple_Naming/README | 262 |
1 files changed, 0 insertions, 262 deletions
diff --git a/TAO/orbsvcs/tests/Simple_Naming/README b/TAO/orbsvcs/tests/Simple_Naming/README deleted file mode 100644 index 5e8c01ad0d3..00000000000 --- a/TAO/orbsvcs/tests/Simple_Naming/README +++ /dev/null @@ -1,262 +0,0 @@ -// $Id$ - -This application tests different features of TAO's Naming Service. - -To run all tests automatically - - execute Perl script run_test.pl - -To run tests manually - - start the Naming Service (see - TAO/orbsvcs/Naming_Service/README for valid options), - then run ./client with one of the options below. - -NOTE: if running tests manually, Naming Service has to be restarted -before each test (this is due to some tests not 'cleaning up' bindings -after themselves). - -The following options exist: ---------------------------- --s Run the Simple test of the Naming Service. - --t Run the Tree test of the Naming Service. - --e Run the Exceptions test of the Naming Service - --i Run the Iterator test of the Naming Service. - --y Run the Destroy test of the Naming Service. - --m <n> Run the Multi-Threaded test of the Naming Service (multiple - client threads). Requires integer argument specifying number - of thread to spawn. (If running this test manually, its - output should be redirected to some file, say, "foo". Then, - "process-m-output.pl" script can be used to analyze the test - output and print out a diagnostic message. Invoke the output - processing script like so: - "process-m-output.pl foo number_of_threads", - where <foo> is the name of the file containing test output, - and <number_of_threads> is the argument that was supplied with - "-m" option to the client.) - - Example (on a Unix system): - $ ../../Naming_Service & - $ ./client -m 10 >& foo - $ ./process-m-output.pl foo 10 - - where the steps correspond to 1)starting the Naming Service, - 2) running the client and redirecting the output to a file, - and 3) running the diagnostic script. - Don't forget to kill the Naming Service after you are done. - -Persistent test consists of two parts (below). - --p <file_name> - Run the Persistent Naming Service test, part 1. Requires an - argument specifying the name of the file in which to store an ior for - use by Persistent Naming Service test, part 2. Note, in order - to test out persistent capabilities of the Naming Service, the - Naming Service must be started with -f and -ORBendpoint options. - The values for these options must be the same for both runs of - the Naming Service (i.e., for part 1 and part 2 of persistent test). - --c <ior> - Run the Persistent Naming Service test, part 2. Requires an - argument specifying the ior, which was produced in part 1 of - the test. Note, in order to test out persistent capabilities - of the Naming Service, the Naming Service must be started with - -f and -ORBendpoint options. The values for these options - must remain the same for both runs of the Naming Service (i.e., - for part 1 and part 2 of persistent test). - - Example of testing persistence on a Unix system: - $ ../../Naming_Service -f log -ORBendpoint iiop://localhost:20000 - $ ./client -p ior_file - kill the Naming_Service process - $ ../../Naming_Service -f log -ORBendpoint iiop://localhost:20000 - $ ./client -c file://ior_file - - where the steps correspond to 1)starting the Naming Service on - port 20000 in persistent mode, with persistent state being - stored in file called "log", 2) running the first part of the - client persistent naming test, and sending its data to file - called "ior_file", 3) killing the Naming Service process, 4) - restarting the Naming Service on the same port with the same - persistent state storage file, and 5) running the second part - of the client persistence test by specifying the ior from part - 1 in the file format. - - We kill the Naming Service process between 2 client runs to - make sure it can recreate its state from persistent storage. - It is necessary to restart the Naming Service on the same - host/port in order for the persistent IORs from the first - run to be valid for the second run. - -If no option is specified, Simple test is run. If more than one -option is specified, only one test runs. - - -DESCRIPTION AND EXPECTED OUTPUT FOR EACH TEST -******************************************* - -Simple Test. - -Performs bind (), resolve (), and unbind () of an object reference in -the root context. - -Expected Output: - -Bound name OK -Resolved name OK -Unbound name OK - -******************************************** - -MT Test. - -Spawns a specified number of threads. Threads concurrently attempt to -bind (), resolve (), and unbind () the object reference. - -Expected Output (produced by the output processing script): - -Multithreaded output is ok - -The output of the actual test varies from run to run, due to the -variation in the thread scheduling. Correct output must have the -following properties (these are the properties that the processing -script checks for): -1) number of bind () calls = number of resolve () calls = number of -unbind () calls = number of threads specified for the test -2) number of successful bind () calls = number of successful unbind () calls. - -******************************************* - -Tree Test. - -Checks all Naming Service functions with a tree of Naming Contexts. - -root->bind_new_context (level1) - -new = root->new_context (), new->bind (foo, obj), and - root->bind_context (level1/level2, new) - -We now have root->level1->level2->foo - -root->resolve (level1/level2/foo). -root->unbind (level1/level2/foo). -root->bind (level1/level2/foo, obj). - -new = root->new_context() -root->rebind_context(level1/level2, new) - -root->bind (level1/level2/foo obj) -root->resolve (level1/level2/foo) -root->rebind (level1/level2/foo, obj2) to have a different object under the name bar. -root->resolve (level1/level2/foo) to make sure correct reference is returned. - - -Expected Output: - -All funtions work properly -******************************************** - -Exceptions Test. - -Makes sure that Naming Service throws exceptions as expected, and data -inside exceptions is set correctly. - -Create a tree of Naming Contexts: root context -> level1 -> level2. - -Bind an object with the name foo into each of the Naming Contexts. - -root->resolve () (with a Name of length 0) - should get InvalidName exception. -root->bind (foo, obj) - should get AlreadyBound exception. -root->bind (level1/foo, obj) - should get AlreadyBound exception. -root->unbind (level1/level2/bar) - should get NotFound exception - with why = missing_node, rest_of_name = bar. -root->unbind (level1/level3/foo) - should get NotFound exception - with why = missing_node, rest_of_name = level3/foo. -root->unbind (level1/foo/foo) -should get NotFound exception - with why = not_context, rest_of_name = foo/foo. - - -Expected Output: - -AlreadyBound exception (case 1) works properly -AlreadyBound exception (case 2) works properly -NotFound exception (case 1) works properly -NotFound exception (case 2) works properly -NotFound exception (case 3) works properly - -********************************************* - -Iterator Test. - -Checks iterator functions. - -Bind () objects with the following names foo1, foo2, foo3, and foo4 -into the root Naming Context. - -root->lists (1, bl, iter) -iter->next_one () -iter->next_n (2, bl) -iter->next_one () - should return false -iter->destroy () - - -Expected Output: - -First binding: foo1 -Second binding: foo2 -Third binding: foo3 -Fourth binding: foo4 - -********************************************* - -Destroy Test. - -Makes sure destroy method is working properly. - -Create a context and bind an object under it. -Attempt to destroy the context - NotEmpty exception should be raised. - -Unbind the object and call destroy on the context. -Attempt to call destroy on the object again - OBJECT_NOT_EXIST -exception should be raised. - - -Expected Output: - -NotEmpty exception works properly -Destroy works properly - -******************************************** - -Persistent Test (part 1). - -Makes sure persistence mode of the Naming Service functions properly: -this test sets things up for part 2 - -Creates the Naming Context hierarchy: -root -> level1_context -> level2_context, -and prints out the ior of the <level1_context> to the specified file. - - -Expected Output: - -Persistent Naming test (part 1) OK. - -******************************************** -Persistent Test (part 2). - -Makes sure persistence mode of the Naming Service functions properly. - -Attempts to resolve <level2_context> both through the ior obtained -from part 1 of the test, and through the Naming Context obtained from -<resolve_initial_references>. Compares the results of both resolve () -calls. - -Expected Output: - -Persistent Naming test (part 2) OK. - -******************************************** |