← Back to branch summary

~statik/ubuntu/maverick/erlang/erlang-merge-testing

« back to all changes in this revision

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

  • Committer: Bazaar Package Importer
  • Author(s): Sergei Golovan
  • Date: 2009-05-01 10:14:38 UTC
  • mfrom: (3.1.4 sid)
  • Revision ID: james.westby@ubuntu.com-20090501101438-6qlr6rsdxgyzrg2z
Tags: 1:13.b-dfsg-2
* Cleaned up patches: removed unneeded patch which helped to support
  different SCTP library versions, made sure that changes for m68k
  architecture applied only when building on this architecture.
* Removed duplicated information from binary packages descriptions.
* Don't require libsctp-dev build-dependency on solaris-i386 architecture
  which allows to build Erlang on Nexenta (thanks to Tim Spriggs for
  the suggestion).

Show diffs side-by-side

added added

removed removed

Lines of Context:
lib/common_test/doc/src/dependencies_chapter.xml
4
4
<chapter>
5
5
  <header>
6
6
    <copyright>
7
 
      <year>2006</year>
8
 
      <year>2008</year>
9
 
      <holder>Ericsson AB, All Rights Reserved</holder>
 
7
      <year>2006</year><year>2009</year>
 
8
      <holder>Ericsson AB. All Rights Reserved.</holder>
10
9
    </copyright>
11
10
    <legalnotice>
12
 
  The contents of this file are subject to the Erlang Public License,
13
 
  Version 1.1, (the "License"); you may not use this file except in
14
 
  compliance with the License. You should have received a copy of the
15
 
  Erlang Public License along with this software. If not, it can be
16
 
  retrieved online at http://www.erlang.org/.
17
 
 
18
 
  Software distributed under the License is distributed on an "AS IS"
19
 
  basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See
20
 
  the License for the specific language governing rights and limitations
21
 
  under the License.
22
 
 
23
 
  The Initial Developer of the Original Code is Ericsson AB.
 
11
      The contents of this file are subject to the Erlang Public License,
 
12
      Version 1.1, (the "License"); you may not use this file except in
 
13
      compliance with the License. You should have received a copy of the
 
14
      Erlang Public License along with this software. If not, it can be
 
15
      retrieved online at http://www.erlang.org/.
 
16
    
 
17
      Software distributed under the License is distributed on an "AS IS"
 
18
      basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See
 
19
      the License for the specific language governing rights and limitations
 
20
      under the License.
 
21
    
24
22
    </legalnotice>
25
23
 
26
24
    <title>Dependencies between Test Cases and Suites</title>
258
256
        case can not run. CT offers a way to declare such dependencies, 
259
257
        called sequences.</p>
260
258
 
261
 
      <p>A sequence of test cases is declared by means of the function
262
 
        <c>sequences/0</c>. This function should return a list of
263
 
        tuples on the format: <c>{SeqTag,TestCases}</c>. <c>SeqTag</c>
264
 
        is an atom that identifies one particular sequence. <c>TestCases</c>
265
 
        is a list of test case names. Sequences must be included in the list 
266
 
        that <c>all/0</c> returns. They are declared as: <c>{sequence,SeqTag}</c>.</p>
 
259
      <p>A sequence of test cases is defined as a test case group
 
260
        with a <c>sequence</c> property. Test case groups are defined by 
 
261
        means of the <c>groups/0</c> function in the test suite (see the 
 
262
        <seealso marker="write_test_chapter#test_case_groups">Test case groups</seealso>
 
263
        chapter for details).</p>
267
264
 
268
265
      <p>For example, if we would like to make sure that if <c>allocate</c>
269
266
        in <c>server_b_SUITE</c> (above) crashes, <c>deallocate</c> is skipped,
270
 
        we may declare the sequence:</p>
 
267
        we may define a sequence like this:</p>
271
268
      
272
269
      <pre>
273
 
        sequences() -> [{alloc_and_dealloc,[alloc,dealloc]}].
274
 
      </pre>
 
270
        groups() -> [{alloc_and_dealloc, [sequence], [alloc,dealloc]}].</pre>
275
271
 
276
272
      <p>Let's also assume the suite contains the test case <c>get_resource_status</c>, 
277
 
        which is independent of the other two cases. The <c>all</c> function could look
278
 
        like this:</p>
 
273
        which is independent of the other two cases, then the <c>all</c> function could 
 
274
        look like this:</p>
279
275
 
280
276
      <pre>
281
 
        all() -> [{sequence,alloc_and_dealloc}, get_resource_status].
282
 
      </pre>
 
277
        all() -> [{group,alloc_and_dealloc}, get_resource_status].</pre>
283
278
 
284
279
      <p>If <c>alloc</c> succeeds, <c>dealloc</c> is also executed. If <c>alloc</c> fails
285
280
        however, <c>dealloc</c> is not executed but marked as SKIPPED in the html log. 
289
284
      <p>Test cases in a sequence will be executed in order until they have all succeeded or 
290
285
        until one case fails. If one fails, all following cases in the sequence are skipped.
291
286
        The cases in the sequence that have succeeded up to that point are reported as successful
292
 
        in the log. An arbitrary number of sequence tuples may be specified. Example:</p>
 
287
        in the log. An arbitrary number of sequences may be specified. Example:</p>
293
288
 
294
289
      <pre>
295
 
        sequences() -> [{scenarioA, [testA1, testA2]}, 
296
 
                        {scenarioB, [testB1, testB2, testB3]}].
 
290
        groups() -> [{scenarioA, [sequence], [testA1, testA2]}, 
 
291
                     {scenarioB, [sequence], [testB1, testB2, testB3]}].
297
292
 
298
293
        all() -> [test1, 
299
294
                  test2, 
300
 
                  {sequence,scenarioA}, 
 
295
                  {group,scenarioA}, 
301
296
                  test3, 
302
 
                  {sequence,scenarioB}, 
303
 
                  test4].
304
 
        </pre>
 
297
                  {group,scenarioB}, 
 
298
                  test4].</pre>
305
299
 
306
 
        <note><p>It is not possible to execute a test case which is part of a sequence as a 
307
 
        regular (stand alone) test case. It is also not possible to use the same test case in
308
 
        multiple sequences. Remember that you can always work around these limitations if
309
 
        necessary by means of help functions common for the test cases in question.</p></note>
 
300
      <p>It is possible to have sub-groups in a sequence group. Such sub-groups can have 
 
301
        any property, i.e. they are not required to also be sequences. If you want the status
 
302
        of the sub-group to affect the sequence on the level above, return 
 
303
        <c>{return_group_result,Status}</c> from <c>end_per_group/2</c>, as described in the
 
304
        <seealso marker="write_test_chapter#repeated_groups">Repeated groups</seealso>
 
305
        chapter. A failed sub-group (<c>Status == failed</c>) will cause the execution of a 
 
306
        sequence to fail in the same way a test case does.</p>
310
307
    </section>
311
308
</chapter>