~ubuntu-branches/ubuntu/trusty/erlang/trusty

« back to all changes in this revision

Viewing changes to lib/common_test/doc/src/ct_master_chapter.xml

  • Committer: Bazaar Package Importer
  • Author(s): Clint Byrum
  • Date: 2011-05-05 15:48:43 UTC
  • mfrom: (3.5.13 sid)
  • Revision ID: james.westby@ubuntu.com-20110505154843-0om6ekzg6m7ugj27
Tags: 1:14.b.2-dfsg-3ubuntu1
* Merge from debian unstable.  Remaining changes:
  - Drop libwxgtk2.8-dev build dependency. Wx isn't in main, and not
    supposed to.
  - Drop erlang-wx binary.
  - Drop erlang-wx dependency from -megaco, -common-test, and -reltool, they
    do not really need wx. Also drop it from -debugger; the GUI needs wx,
    but it apparently has CLI bits as well, and is also needed by -megaco,
    so let's keep the package for now.
  - debian/patches/series: Do what I meant, and enable build-options.patch
    instead.
* Additional changes:
  - Drop erlang-wx from -et
* Dropped Changes:
  - patches/pcre-crash.patch: CVE-2008-2371: outer level option with
    alternatives caused crash. (Applied Upstream)
  - fix for ssl certificate verification in newSSL: 
    ssl_cacertfile_fix.patch (Applied Upstream)
  - debian/patches/series: Enable native.patch again, to get stripped beam
    files and reduce the package size again. (build-options is what
    actually accomplished this)
  - Remove build-options.patch on advice from upstream and because it caused
    odd build failures.

Show diffs side-by-side

added added

removed removed

Lines of Context:
4
4
<chapter>
5
5
  <header>
6
6
    <copyright>
7
 
      <year>2006</year><year>2009</year>
 
7
      <year>2006</year><year>2010</year>
8
8
      <holder>Ericsson AB. All Rights Reserved.</holder>
9
9
    </copyright>
10
10
    <legalnotice>
13
13
      compliance with the License. You should have received a copy of the
14
14
      Erlang Public License along with this software. If not, it can be
15
15
      retrieved online at http://www.erlang.org/.
16
 
    
 
16
 
17
17
      Software distributed under the License is distributed on an "AS IS"
18
18
      basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See
19
19
      the License for the specific language governing rights and limitations
20
20
      under the License.
21
 
    
 
21
 
22
22
    </legalnotice>
23
23
 
24
24
    <title>Using Common Test for Large Scale Testing</title>
30
30
  </header>
31
31
 
32
32
  <section>
 
33
    <marker id="general"></marker>
33
34
    <title>General</title>
34
35
    <p>Large scale automated testing requires running multiple independent 
35
36
      test sessions in parallel. This is accomplished by running
102
103
      <p><c>ct_master:abort()</c> (stop all) or <c>ct_master:abort(Nodes)</c></p>
103
104
 
104
105
      <p>For detailed information about the <c>ct_master</c> API, please see the 
105
 
      manual page for this module.</p>
 
106
      <seealso marker="ct_master">manual page</seealso> for this module.</p>
106
107
  </section>
107
108
  <section>
 
109
    <marker id="test_specifications"></marker>
108
110
    <title>Test Specifications</title>
109
111
    <p>The test specifications used as input to CT Master are fully compatible with the
110
112
    specifications used as input to the regular CT server. The syntax is described in the 
186
188
    <seealso marker="run_test_chapter#test_specifications">Running Test Suites</seealso>
187
189
    chapter). The result is that any test specified to run on a node with the same
188
190
    name as the Common Test node in question (typically <c>ct@somehost</c> if started
189
 
    with the <c>run_test</c> script), will be performed. Tests without explicit
 
191
    with the <c>ct_run</c> program), will be performed. Tests without explicit
190
192
    node association will always be performed too of course!</p>
191
193
 
192
194
    <note><p>It is recommended that absolute paths are used for log directories,
194
196
    current working directory settings are not important.</p></note>
195
197
  </section>
196
198
 
 
199
  <section>
 
200
    <title>Automatic startup of test target nodes</title>
 
201
    <marker id="ct_slave"></marker>
 
202
    <p>Is is possible to automatically start, and perform initial actions, on
 
203
      test target nodes by using the test specification term <c>init</c>.</p>
 
204
    <p>Currently, two sub-terms are supported, <c>node_start</c> and <c>eval</c>.</p>
 
205
    <p>Example:</p>
 
206
    <pre>
 
207
     {node, node1, node1@host1}.
 
208
     {node, node2, node1@host2}.
 
209
     {node, node3, node2@host2}.
 
210
     {node, node4, node1@host3}.
 
211
     {init, node1, [{node_start, [{callback_module, my_slave_callback}]}]}.
 
212
     {init, [node2, node3], {node_start, [{username, "ct_user"}, {password, "ct_password"}]}}.
 
213
     {init, node4, {eval, {module, function, []}}}.</pre>
 
214
 
 
215
    <p>This test specification declares that <c>node1@host1</c> is to be started using
 
216
      the user callback function <c>callback_module:my_slave_callback/0</c>, and nodes
 
217
      <c>node1@host2</c> and <c>node2@host2</c> will be started with the default callback
 
218
      module <c>ct_slave</c>. The given user name and password is used to log into remote
 
219
      host <c>host2</c>. Also, the function <c>module:function/0</c> will be evaluated on
 
220
      <c>node1@host3</c>, and the result of this call will be printed to the log.</p>
 
221
 
 
222
    <p>The default <seealso marker="ct_slave">ct_slave</seealso> callback module,
 
223
      which is part of the Common Test application, has the following features:
 
224
    <list>
 
225
     <item>Starting Erlang target nodes on local or remote hosts
 
226
       (ssh is used for communication).
 
227
     </item>
 
228
     <item>Ability to start an Erlang emulator with additional flags
 
229
       (any flags supported by <c>erl</c> are supported).
 
230
     </item>
 
231
     <item>Supervision of a node being started by means of internal callback
 
232
        functions. Used to prevent hanging nodes. (Configurable).
 
233
     </item>
 
234
     <item>Monitoring of the master node by the slaves. A slave node may be
 
235
        stopped in case the master node terminates. (Configurable).
 
236
     </item>
 
237
     <item>Execution of user functions after a slave node is started.
 
238
        Functions can be given as a list of {Module, Function, Arguments} tuples.
 
239
     </item>
 
240
    </list>
 
241
    </p>
 
242
    <p>Note that it is possible to specify an <c>eval</c> term for the node as well
 
243
    as <c>startup_functions</c> in the <c>node_start</c> options list. In this
 
244
    case first the node will be started, then the <c>startup_functions</c> are
 
245
    executed, and finally functions specified with <c>eval</c> are called.
 
246
    </p>
 
247
  </section>
 
248
 
197
249
</chapter>
198
250
 
199
251