From eda9f3c82d3241549352969c59488b232e902d69 Mon Sep 17 00:00:00 2001
From: Andrey Pampukha The nature of the configuration variables can be not only plain text
- files with the key-value tuples, but they can be loaded from the files in
+ files with the key-value tuples, they also can be loaded from the files in
various formats, fetched via http from the Web, or can be loaded with help
of some driver process. For this purpose, mechanism of plugging in user
configuration handling callback modules is implemented in the Common Test. This configuration file, once read, will produce the same configuration
- variables as the following "traditional" file:
{ftp_host, [{ftp,"targethost"}, {username,"tester"}, @@ -237,13 +237,13 @@Implementing of the own handler Own handler can be written to handle special configuration file formats. - The parameter can be either file name or configuration string (empty list + The parameter can be either file name(s) or configuration string (empty list is valid).
The callback module is completely responsible for the configuration string correctness checks during runtime.
-Callback module should have the following functions exported:
-One for checking configuration parameter
+To perform validation of the configuration string, callback module + should have the following function exported:
Callback:check_parameter/1 Input value will be passed from the Common Test, as defined in the test @@ -269,22 +269,25 @@ -
And second function performs reading of the configuration variables:
+To perform actual reading, in cases of initial loading of the + configuration variables and runtime re-loading, function
+
Callback:read_config/1 should be exported from the callback module
Input value is the same as for
check_parameter/1 functionReturn value should be either:
-
- -
{ok, Config} - is configuration variables read successfully; +{ok, Config} - if configuration variables read successfully;{error, Error, ErrorDetails} - if callback module failed to - proceed. + proceed with the given configuration parameters.Above, the
+Config variable is the key-value list, possibly nested, - e.g. for the configuration files above it will be the followingAbove, the
Config variable is the proper Erlang key-value list, + with possible key-value sublists as values, + e.g. for the configuration files above it will be the following:[{ftp_host, [{ftp, "targethost"}, {username, "tester"}, {password, "letmein"}]}, @@ -310,9 +313,9 @@XML version shown in chapter above can also be used, but it should be explicitly specified that
+ used by the Common Test. -ct_config_xml callback module is to be - used.Example of how to assert that the configuration data is available and +
Example of how to assert that the configuration data is available and use it for an FTP session:
init_per_testcase(ftptest, Config) -> @@ -359,7 +362,8 @@Example of own configuration handler -Simple configuration hanling "driver" can be implemented this way:
+Simple configuration hanling driver which will ask external server for + configuration data can be implemented this way:
-module(config_driver). -export([read_config/1, check_parameter/1]). @@ -384,7 +388,8 @@ check_parameter(ServerName)-> end.Configuration string for this driver may be "config_server", if the - config_server.erl module below is built and is exist in the code path:
+ config_server.erl module below is built and is exist in the code path + during test execution:-module(config_server). -export([start/0, stop/0, init/1, get_config/0, loop/0]). -- cgit v1.2.3