WL#8462: Plugin(s) to test services of server
To support the implementation of plugins there exist services (APIs) like "my_snprintf" or "my_plugin_log_message". To test these services systematically one or more plugins will be needed. A kind of test frame work or example plugin(s) shall be provided to show how tests for services can be implemented. Goal is to run these test plugins with mtr. That allows to assure( and show) the interaction between plugin, plugin service and SQL.
FR1: The test plugin must be a normal plugin to install/uninstall in mtr tests (as usual), preferably one of the existing plugin types. FR2: The results of tested services must be visible in mtr result files. FR3: A test plugin must be provided serving as example. FR4: The example test plugin must be extendable by adding more test cases for services. FR5: A minimal frame work for new test plugins for services must be available as base for implementing new test plugins.
As base for the test plugin on server side the daemon plugin type can be taken. It will be loaded (started) with the sql statement "INSTALL PLUGIN" and unloaded (stopped) by calling "UNINSTALL PLUGIN". There is no other communication between server and daemon unless it will be explicitly implemented e.g. with the help of an API or service. INSTALL and UNINSTALL will be executed by a mtr test. It may of course contain other sql statements. The plugin shall write its test results into one or more files. These files can then be written into the result file of the mtr test with the normal mtr commands like "cat_file". The plugin can also write messages into "mysqld.1.err". These messages can be made visible in the result file or checked as follows: Load this log into a table with 2 columns (date, info). Info will be selected by removing '\r' to be compatible to windows (The err log file on windows contains CR,LF as newline). Select the messages so they will be visible in the mtr result file. A perl snippet can be used for that purpose, too. In a plugin status and system (sql) variables can be specified. With status variables the state of the test execution can be reported to the mtr test calling the test plugin. That might be useful to e.g. give a ready message for a test case or the whole plugin. Especially when using threads in a test plugin such status variables are useful to synchronize execution of plugin and mtr test as both are running in parallel. System variables can be used to e.g. control test execution. But, that is very rudimentary as it is more kind of configuration at start of the plugin.
The test plugin consisting of - the directory "test_services" to put into plugin directory - the mtr test "test_services.test" and the result file to put into main. Test_services contains the "test_services.cc" showing how to test services, here "my_snprintf" and "my_plugin_log_message". For each of the services there is a function implemented containing the test cases (actually not complete). Instead of using the standard I/O of C++ it is much more comfortable to used "my_open", "my_write", etc. as it covers all platforms. The output of "my_snprintf" can be found in "var/mysqld.1/data/test_services.log". "my_plugin_log_message" writes into "mysqld.1.err". The (selected) contents of these files can be seen in the result file of "test_services.test". "test_services.test" didn't create a thread. The effect is that the test (mysqld) is waiting until the plugin completes its work. A waiting condition is basically not necessary. The plugin "test_service_threaded.cc" runs the tests in a thread. This needs synchronization of plugin and mtr runs as both are running in parallel. The synchronization will be done by waiting for the plugin (exactly the thread in the plugin) to be finished. If the thread is needing a very long time then the mtr test may run in a timeout. The test plugin "test_framework.cc" is a rudimentary implementation of a daemon plugin, which can be take to create new one. It might be better to copy one of "test_services" examples and modify it, depending of the need of threads or not. Using threads has the advantage of limiting test execution with a timeout. That may be interesting for long running plugins testing complex API tests. Plugins needing a short run time may run without threads.
Copyright (c) 2000, 2019, Oracle Corporation and/or its affiliates. All rights reserved.