diff options
Diffstat (limited to 'TAO/orbsvcs/tests/Simple_Naming/README')
| -rw-r--r-- | TAO/orbsvcs/tests/Simple_Naming/README | 262 |
1 files changed, 262 insertions, 0 deletions
diff --git a/TAO/orbsvcs/tests/Simple_Naming/README b/TAO/orbsvcs/tests/Simple_Naming/README new file mode 100644 index 00000000000..5e8c01ad0d3 --- /dev/null +++ b/TAO/orbsvcs/tests/Simple_Naming/README @@ -0,0 +1,262 @@ +// $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. + +******************************************** |