From a95a238719369feb1002daeacf4e1485439a38d2 Mon Sep 17 00:00:00 2001 From: Lukas Larsson Date: Tue, 21 Aug 2012 17:44:49 +0200 Subject: Add more cross reference links to ct docs --- lib/common_test/doc/src/common_test_app.xml | 53 +++++++++++----------- lib/common_test/doc/src/config_file_chapter.xml | 17 +++---- lib/common_test/doc/src/cover_chapter.xml | 2 +- lib/common_test/doc/src/ct_hooks_chapter.xml | 4 +- lib/common_test/doc/src/ct_run.xml | 2 +- lib/common_test/doc/src/event_handler_chapter.xml | 6 +-- .../doc/src/getting_started_chapter.xml | 2 +- lib/common_test/doc/src/run_test_chapter.xml | 23 +++++----- lib/common_test/doc/src/write_test_chapter.xml | 20 ++++---- lib/common_test/src/ct_ftp.erl | 8 ++-- lib/common_test/src/ct_netconfc.erl | 2 +- lib/common_test/src/ct_ssh.erl | 6 +-- 12 files changed, 75 insertions(+), 70 deletions(-) diff --git a/lib/common_test/doc/src/common_test_app.xml b/lib/common_test/doc/src/common_test_app.xml index addeed002a..a0fa45c71f 100644 --- a/lib/common_test/doc/src/common_test_app.xml +++ b/lib/common_test/doc/src/common_test_app.xml @@ -99,11 +99,11 @@ be executed by Common Test. A test case is represented by an atom, the name of the test case function. A test case group is represented by a group tuple, where GroupName, - an atom, is the name of the group (defined in groups/0). + an atom, is the name of the group (defined in groups/0). Execution properties for groups may also be specified, both for a top level group and for any of its sub-groups. Group execution properties specified here, will override - properties in the group definition (see groups/0). + properties in the group definition (see groups/0). (With value default, the group definition properties will be used).

@@ -184,8 +184,8 @@ test cases in the suite).

The timetrap tag sets the maximum time each - test case is allowed to execute (including init_per_testcase/2 - and end_per_testcase/2). If the timetrap time is + test case is allowed to execute (including init_per_testcase/2 + and end_per_testcase/2). If the timetrap time is exceeded, the test case fails with reason timetrap_timeout. A TimeFunc function can be used to set a new timetrap by returning a TimeVal. It may also be @@ -201,11 +201,11 @@ in any of the configuration files, all test cases are skipped. For more information about the 'require' functionality, see the reference manual for the function - ct:require/[1,2].

+ ct:require/1/2.

With userdata, it is possible for the user to specify arbitrary test suite related information which can be - read by calling ct:userdata/2.

+ read by calling ct:userdata/2.

The ct_hooks tag specifies which Common Test Hooks @@ -264,7 +264,7 @@

This function is called as the last test case in the suite. It is meant to be used for cleaning up after - init_per_suite/1. + init_per_suite/1. For information on save_config, please see Dependencies between Test Cases and Suites in the User's Guide.

@@ -309,13 +309,14 @@

This is the test case group info function. It is supposed to return a list of tagged tuples that specify various properties related to the execution of a test case group (i.e. its test cases - and sub-groups). Properties set by groups/1 override + and sub-groups). Properties set by + group/1 override properties with the same key that have been previously set by - suite/0.

+ suite/0.

The timetrap tag sets the maximum time each - test case is allowed to execute (including init_per_testcase/2 - and end_per_testcase/2). If the timetrap time is + test case is allowed to execute (including init_per_testcase/2 + and end_per_testcase/2). If the timetrap time is exceeded, the test case fails with reason timetrap_timeout. A TimeFunc function can be used to set a new timetrap by returning a TimeVal. It may also be @@ -330,11 +331,11 @@ in any of the configuration files, all test cases in this group are skipped. For more information about the 'require' functionality, see the reference manual for the function - ct:require/[1,2].

+ ct:require/1/2.

With userdata, it is possible for the user to specify arbitrary test case group related information which can be - read by calling ct:userdata/2.

+ read by calling ct:userdata/2.

The ct_hooks tag specifies which Common Test Hooks @@ -367,7 +368,7 @@ test case group. It typically contains initializations which are common for all test cases and sub-groups in the group, and which shall only be performed once. GroupName is the name of the - group, as specified in the group definition (see groups/0). The + group, as specified in the group definition (see groups/0). The Config parameter is the configuration data which can be modified here. The return value of this function is given as Config to all test cases and sub-groups in the group. If {skip,Reason} @@ -396,10 +397,10 @@

OPTIONAL

This function is called after the execution of a test case group is finished. - It is meant to be used for cleaning up after init_per_group/2. + It is meant to be used for cleaning up after init_per_group/2. By means of {return_group_result,Status}, it is possible to return a status value for a nested sub-group. The status can be retrieved in - end_per_group/2 for the group on the level above. The status will also + end_per_group/2 for the group on the level above. The status will also be used by Common Test for deciding if execution of a group should proceed in case the property sequence or repeat_until_* is set.

@@ -450,7 +451,7 @@

OPTIONAL

This function is called after each test case, and can be used - to clean up after init_per_testcase/2 and the test case. + to clean up after init_per_testcase/2 and the test case. Any return value (besides {fail,Reason} and {save_config,SaveConfig}) is ignored. By returning {fail,Reason}, TestCase will be marked as failed (even though it was actually successful in the sense that it returned @@ -492,15 +493,15 @@

This is the test case info function. It is supposed to return a list of tagged tuples that specify various properties related to the execution of this particular test case. - Properties set by Testcase/0 override + Properties set by Testcase/0 override properties that have been previously set for the test case - by group/1 or suite/0.

+ by group/1 or suite/0.

The timetrap tag sets the maximum time the test case is allowed to execute. If the timetrap time is exceeded, the test case fails with reason - timetrap_timeout. init_per_testcase/2 - and end_per_testcase/2 are included in the + timetrap_timeout. init_per_testcase/2 + and end_per_testcase/2 are included in the timetrap time. A TimeFunc function can be used to set a new timetrap by returning a TimeVal. It may also be used to trigger a timetrap timeout by, at some point, returning a @@ -514,15 +515,15 @@ configuration files, the test case is skipped. For more information about the 'require' functionality, see the reference manual for the function - ct:require/[1,2].

+ ct:require/1/2.

If timetrap and/or require is not set, the - default values specified by suite/0 (or - group/1) will be used.

+ default values specified by suite/0 (or + group/1) will be used.

With userdata, it is possible for the user to specify arbitrary test case related information which can be - read by calling ct:userdata/3.

+ read by calling ct:userdata/3.

Other tuples than the ones defined will simply be ignored.

@@ -550,7 +551,7 @@

This is the implementation of a test case. Here you must call the functions you want to test, and do whatever you need to check the result. If something fails, make sure the - function causes a runtime error, or call ct:fail/1/2 + function causes a runtime error, or call ct:fail/1/2 (which also causes the test case process to terminate).

Elements from the Config list can e.g. be read diff --git a/lib/common_test/doc/src/config_file_chapter.xml b/lib/common_test/doc/src/config_file_chapter.xml index 706d0d5f4e..e843ed3ba4 100644 --- a/lib/common_test/doc/src/config_file_chapter.xml +++ b/lib/common_test/doc/src/config_file_chapter.xml @@ -78,7 +78,7 @@ test is skipped (unless a default value has been specified, see the test case info function chapter for details). There is also a function - ct:require/[1,2] which can be called from a test case + ct:require/1/2 which can be called from a test case in order to check if a specific variable is available. The return value from this function must be checked explicitly and appropriate action be taken depending on the result (e.g. to skip the test case @@ -88,7 +88,7 @@ info-list should look like this: {require,CfgVarName} or {require,AliasName,CfgVarName}. The arguments AliasName and CfgVarName are the same as the - arguments to ct:require/[1,2] which are described in the + arguments to ct:require/1/2 which are described in the reference manual for ct. AliasName becomes an alias for the configuration variable, and can be used as reference to the configuration data value. @@ -101,7 +101,8 @@ (or test case) and improve readability.

To read the value of a config variable, use the function - get_config/[1,2,3] which is also described in the reference + get_config/1/2/3 + which is also described in the reference manual for ct.

Example:

@@ -118,7 +119,7 @@
   

   Using configuration variables defined in multiple files
     
If a configuration variable is defined in multiple files and you 
-      want to access all possible values, you may use the ct:get_config/3
+      want to access all possible values, you may use the ct:get_config/3
       function and specify all in the options list. The values will then
       be returned in a list and the order of the elements corresponds to the order 
       that the config files were specified at startup. Please see 
@@ -130,7 +131,7 @@
     
     
It is possible to encrypt configuration files containing sensitive data
       if these files must be stored in open and shared directories.
 
-      
Call ct:encrypt_config_file/[2,3] to have Common Test encrypt a 
+      
Call ct:encrypt_config_file/2/3 to have Common Test encrypt a
       specified file using the DES3 function in the OTP crypto application.
       The encrypted file can then be used as a regular configuration file,
       in combination with other encrypted files or normal text files. The key
@@ -139,7 +140,7 @@
       decrypt_file flag/option, or a key file in a predefined location.

       
       
Common Test also provides decryption functions, 
-      ct:decrypt_config_file/[2,3], for recreating the original text
+      ct:decrypt_config_file/2/3, for recreating the original text
       files.
 
 
       
Please see the ct reference manual for
@@ -149,8 +150,8 @@
   

     Opening connections by using configuration data
     
There are two different methods for opening a connection
-      by means of the support functions in e.g. ct_ssh, ct_ftp,
-      and ct_telnet:

+      by means of the support functions in e.g. ct_ssh, ct_ftp,
+      and ct_telnet:

     
       Using a configuration target name (an alias) as reference.
       Using the configuration variable as reference.
diff --git a/lib/common_test/doc/src/cover_chapter.xml b/lib/common_test/doc/src/cover_chapter.xml
index b7162cb542..fc609ee137 100644
--- a/lib/common_test/doc/src/cover_chapter.xml
+++ b/lib/common_test/doc/src/cover_chapter.xml
@@ -100,7 +100,7 @@
     
$ ct_run -dir $TESTOBJS/db -cover $TESTOBJS/db/config/db.coverspec

     
     
You may also pass the cover specification file name in a
-      call to ct:run_test/1, by adding a {cover,CoverSpec}
+      call to ct:run_test/1, by adding a {cover,CoverSpec}
       tuple to the Opts argument. Also, you can of course 
       enable code coverage in your test specifications (read
       more in the chapter about 
diff --git a/lib/common_test/doc/src/ct_hooks_chapter.xml b/lib/common_test/doc/src/ct_hooks_chapter.xml
index 014507c886..c938851e0e 100644
--- a/lib/common_test/doc/src/ct_hooks_chapter.xml
+++ b/lib/common_test/doc/src/ct_hooks_chapter.xml
@@ -192,12 +192,12 @@
     

       External configuration data and Logging
       
It's possible in the CTH to read configuration data values
-	by calling ct:get_config/1/2/3 (as explained in the
+	by calling ct:get_config/1/2/3 (as explained in the
 	
 	  External configuration data
 	chapter). The config variables in question must, as always, first have been
 	required by means of a suite-, group-, or test case info function,
-	or the ct:require/1/2 function. Note that the latter can also be used
+	or the ct:require/1/2 function. Note that the latter can also be used
 	in CT hook functions.

       
The CT hook functions may call any of the logging functions available
 	in the ct interface to print information to the log files, or to
diff --git a/lib/common_test/doc/src/ct_run.xml b/lib/common_test/doc/src/ct_run.xml
index 078b9b958c..434cb7da7c 100644
--- a/lib/common_test/doc/src/ct_run.xml
+++ b/lib/common_test/doc/src/ct_run.xml
@@ -46,7 +46,7 @@
     particular mode.

 
   
There is an interface function that corresponds to this program,
-    called ct:run_test/1, for starting Common Test from the Erlang
+    called ct:run_test/1, for starting Common Test from the Erlang
     shell (or an Erlang program). Please see the ct man page for
     details.

 
diff --git a/lib/common_test/doc/src/event_handler_chapter.xml b/lib/common_test/doc/src/event_handler_chapter.xml
index 2f796b91ab..b95a18e47e 100644
--- a/lib/common_test/doc/src/event_handler_chapter.xml
+++ b/lib/common_test/doc/src/event_handler_chapter.xml
@@ -64,7 +64,7 @@
     
     Usage
     
Event handlers may be installed by means of an event_handler
-    start flag (ct_run) or option (ct:run_test/1), where the
+    start flag (ct_run) or option (ct:run_test/1), where the
     argument specifies the names of one or more event handler modules.
     Example:

     
$ ct_run -suite test/my_SUITE -event_handler handlers/my_evh1 
@@ -78,7 +78,7 @@
     example).

 
     
An event_handler tuple in the argument Opts has the following
-      definition (see also ct:run_test/1 in the reference manual):

+      definition (see also ct:run_test/1 in the reference manual):

 
     
     {event_handler,EventHandlers}
@@ -308,7 +308,7 @@
     manager can look like.

 
     
To ensure that printouts to standard out (or printouts made with
-    ct:log/2/3 or ct:pal/2/3) get written to the test case log
+    ct:log/2/3 or ct:pal/2/3) get written to the test case log
     file, and not to the Common Test framework log, you can syncronize
     with the Common Test server by matching on the tc_start and tc_done
     events. In the period between these events, all IO gets directed to the
diff --git a/lib/common_test/doc/src/getting_started_chapter.xml b/lib/common_test/doc/src/getting_started_chapter.xml
index 039578dd2e..891cbc49f3 100644
--- a/lib/common_test/doc/src/getting_started_chapter.xml
+++ b/lib/common_test/doc/src/getting_started_chapter.xml
@@ -90,7 +90,7 @@
     
As you can understand from the illustration above, Common Test requires
       that a test case generates a runtime error to indicate failure (e.g.
       by causing a bad match error or by calling exit/1, preferrably
-      through the ct:fail/1,2 help function). A succesful execution is
+      through the ct:fail/1,2 help function). A succesful execution is
       indicated by means of a normal return from the test case function.
     

     

diff --git a/lib/common_test/doc/src/run_test_chapter.xml b/lib/common_test/doc/src/run_test_chapter.xml
index 30486d3eec..c1f68becc3 100644
--- a/lib/common_test/doc/src/run_test_chapter.xml
+++ b/lib/common_test/doc/src/run_test_chapter.xml
@@ -242,12 +242,12 @@
     
     
Common Test provides an Erlang API for running tests. The main (and most
       flexible) function for specifying and executing tests is called
-      ct:run_test/1. This function takes the same start parameters as
+      ct:run_test/1. This function takes the same start parameters as
       the ct_run program described above, only the flags are instead
       given as options in a list of key-value tuples. E.g. a test specified 
       with ct_run like:

       
$ ct_run -suite ./my_SUITE -logdir ./results
 
-      
is with ct:run_test/1 specified as:
 
+      
is with ct:run_test/1 specified as:

       
1> ct:run_test([{suite,"./my_SUITE"},{logdir,"./results"}]).

       
For detailed documentation, please see the ct manual page.
    
   

@@ -266,9 +266,9 @@
       for trying out various operations during test suite development.

 
     
To invoke the interactive shell mode, you can start an Erlang shell 
-      manually and call ct:install/1 to install any configuration
+      manually and call ct:install/1 to install any configuration
       data you might need (use [] as argument otherwise), then
-      call ct:start_interactive/0 to start Common Test. If you use
+      call ct:start_interactive/0 to start Common Test. If you use
       the ct_run program, you may start the Erlang shell and Common Test
       in the same go by using the -shell and, optionally, the -config
       and/or -userconfig flag. Examples:
@@ -287,7 +287,8 @@
     
     
If any functions using "required config data" (e.g. ct_telnet or
       ct_ftp functions) are to be called from the erlang shell, config
-      data must first be required with ct:require/[1,2]. This is
+      data must first be required with 
+      ct:require/1/2. This is
       equivalent to a require statement in the Test Suite Info 
 	Function or in the 
     
     
If you wish to exit the interactive mode (e.g. to start an
-      automated test run with ct:run_test/1), call the function 
-      ct:stop_interactive/0. This shuts down the
+      automated test run with ct:run_test/1), call the function
+      ct:stop_interactive/0. This shuts down the
       running ct application. Associations between
       configuration names and data created with require are 
-      consequently deleted. ct:start_interactive/0 will get you 
+      consequently deleted. ct:start_interactive/0 will get you
       back into interactive mode, but the previous state is not restored.

   

 
@@ -326,7 +327,7 @@
     Step by step execution of test cases with the Erlang Debugger
    
     
By means of ct_run -step [opts], or by passing the 
-       {step,Opts} option to ct:run_test/1, it is possible
+       {step,Opts} option to ct:run_test/1, it is possible
        to get the Erlang Debugger started automatically and use its
        graphical interface to investigate the state of the current test 
        case and to execute it step by step and/or set execution breakpoints.

@@ -586,7 +587,7 @@
       ct_run. This forces Common Test to ignore unrecognizable terms.
       Note that in this mode, Common Test is not able to check the specification 
       for errors as efficiently as if the scanner runs in default mode. 
-      If ct:run_test/1 is used for starting the tests, the relaxed scanner 
+      If ct:run_test/1 is used for starting the tests, the relaxed scanner
       mode is enabled by means of the tuple: {allow_user_terms,true}

   
   
@@ -943,7 +944,7 @@
       
       
The -silent_connections tag (or
 	silent_connections tagged tuple in the call to
-	ct:run_test/1) overrides any settings in the test
+	ct:run_test/1) overrides any settings in the test
 	suite.

       
       
Note that in the current Common Test version, the
diff --git a/lib/common_test/doc/src/write_test_chapter.xml b/lib/common_test/doc/src/write_test_chapter.xml
index d545c9e432..1fae50577e 100644
--- a/lib/common_test/doc/src/write_test_chapter.xml
+++ b/lib/common_test/doc/src/write_test_chapter.xml
@@ -173,7 +173,7 @@
     

 
     
The end_per_testcase/2 function is called even after a
-      test case terminates due to a call to ct:abort_current_testcase/1,
+      test case terminates due to a call to ct:abort_current_testcase/1,
       or after a timetrap timeout. However, end_per_testcase
       will then execute on a different process than the test case
       function, and in this situation, end_per_testcase will
@@ -243,7 +243,8 @@
 
     
The test case function argument Config should not be 
 	confused with the information that can be retrieved from 
-	configuration files (using ct:get_config/[1,2]). The Config argument 
+	configuration files (using 
+	ct:get_config/1/2). The Config argument
 	should be used for runtime configuration of the test suite and the 
 	test cases, while configuration files should typically contain data 
 	related to the SUT. These two types of configuration data are handled 
@@ -302,7 +303,7 @@
 	
 	  

 	    Use this to specify arbitrary data related to the testcase. This
-	    data can be retrieved at any time using the ct:userdata/3 
+	    data can be retrieved at any time using the ct:userdata/3
 	    utility function.
 	  

 	
@@ -347,7 +348,8 @@
       
 
 	
See the Config files
-	  chapter and the ct:require/[1,2] function in the
+	  chapter and the 
+	  ct:require/1/2 function in the
 	   ct reference manual for more information about
 	   require.

 
@@ -824,7 +826,7 @@
       Common Test to create one dedicated private directory per
       test case and execution instead. This is accomplished by means of
       the flag/option: create_priv_dir (to be used with the
-      ct_run program, the ct:run_test/1 function, or
+      ct_run program, the ct:run_test/1 function, or
       as test specification term). There are three possible values
       for this option:
       
@@ -840,7 +842,7 @@
       become very inefficient for test runs with many test cases and/or
       repetitions. Therefore, in case the manual version is instead used, the
       test case must tell Common Test to create priv_dir when it needs it.
-      It does this by calling the function ct:make_priv_dir/0.
+      It does this by calling the function ct:make_priv_dir/0.
       

 
       
You should not depend on current working directory for
@@ -888,7 +890,7 @@
     
     
It is also possible to dynamically set/reset a timetrap during the
     excution of a test case, or configuration function. This is done by calling
-    ct:timetrap/1. This function cancels the current timetrap
+    ct:timetrap/1. This function cancels the current timetrap
     and starts a new one (that stays active until timeout, or end of the
     current function).

     
@@ -901,12 +903,12 @@
     
     
If a test case needs to suspend itself for a time that also gets
     multipled by multiply_timetraps (and possibly also scaled up if
-    scale_timetraps is enabled), the function ct:sleep/1
+    scale_timetraps is enabled), the function ct:sleep/1
     may be used (instead of e.g. timer:sleep/1).

     
     
A function (fun/0 or MFA) may be specified as
     timetrap value in the suite-, group- and test case info function, as
-    well as argument to the ct:timetrap/1 function. Examples:

+    well as argument to the ct:timetrap/1 function. Examples:

 
     
{timetrap,{my_test_utils,timetrap,[?MODULE,system_start]}}

     
ct:timetrap(fun() -> my_timetrap(TestCaseName, Config) end)

diff --git a/lib/common_test/src/ct_ftp.erl b/lib/common_test/src/ct_ftp.erl
index d1d511f137..723715c986 100644
--- a/lib/common_test/src/ct_ftp.erl
+++ b/lib/common_test/src/ct_ftp.erl
@@ -66,7 +66,7 @@
 %%% {unix,[{ftp,IpAddr},
 %%%        {username,Username},
 %%%        {password,Password}]}.
-%%% @see ct:require/3 +%%% @see ct:require/2 put(KeyOrName,LocalFile,RemoteFile) -> Fun = fun(Ftp) -> send(Ftp,LocalFile,RemoteFile) end, open_and_do(KeyOrName,Fun). @@ -86,7 +86,7 @@ put(KeyOrName,LocalFile,RemoteFile) -> %%% %%%

The config file must be as for put/3.

%%% @see put/3 -%%% @see ct:require/3 +%%% @see ct:require/2 get(KeyOrName,RemoteFile,LocalFile) -> Fun = fun(Ftp) -> recv(Ftp,RemoteFile,LocalFile) end, open_and_do(KeyOrName,Fun). @@ -108,9 +108,9 @@ get(KeyOrName,RemoteFile,LocalFile) -> %%% specify the target. Note that a connection that has no associated target %%% name can only be closed with the handle value.

%%% -%%%

See ct:require/3 for how to create a new Name

+%%%

See ct:require/2 for how to create a new Name

%%% -%%% @see ct:require/3 +%%% @see ct:require/2 open(KeyOrName) -> case ct_util:get_key_from_name(KeyOrName) of {ok,node} -> diff --git a/lib/common_test/src/ct_netconfc.erl b/lib/common_test/src/ct_netconfc.erl index 8d2e25b946..a6b170f07e 100644 --- a/lib/common_test/src/ct_netconfc.erl +++ b/lib/common_test/src/ct_netconfc.erl @@ -408,7 +408,7 @@ open(Options) -> %% server. It is not used for any other purposes during the lifetime %% of the connection. %% -%% @see ct:require/3 +%% @see ct:require/2 %% @end %%---------------------------------------------------------------------- open(KeyOrName, ExtraOpts) -> diff --git a/lib/common_test/src/ct_ssh.erl b/lib/common_test/src/ct_ssh.erl index 21553f5551..81a25849db 100644 --- a/lib/common_test/src/ct_ssh.erl +++ b/lib/common_test/src/ct_ssh.erl @@ -133,10 +133,10 @@ connect(KeyOrName, ExtraOpts) when is_list(ExtraOpts) -> %%% is used to identify the connection, this name may %%% be used as connection reference for subsequent calls. %%% It's only possible to have one open connection at a time -%%% associated with Name. If Key is +%%% associated with Name. If Key is %%% used, the returned handle must be used for subsequent calls %%% (multiple connections may be opened using the config -%%% data specified by Key). See ct:require/3 +%%% data specified by Key). See ct:require/2 %%% for how to create a new Name

%%% %%%

ConnType will always override the type @@ -154,7 +154,7 @@ connect(KeyOrName, ExtraOpts) when is_list(ExtraOpts) -> %%% same key in the config data. For details on valid SSH %%% options, see the documentation for the OTP ssh application.

%%% -%%% @see ct:require/3 +%%% @see ct:require/2 connect(KeyOrName, ConnType, ExtraOpts) -> case ct:get_config(KeyOrName) of undefined -> -- cgit v1.2.3