1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
|
======================
Open Test presentation
======================
:Author: Baptiste Lepilleur
:Contact: blep@users.sourceforge.net
.. contents::
What is Open Test?
==================
Open Test provides a mean to easily integrate a testing framework
with Open Test `test drivers`__.
__ TestDriver_
The open test concept emerged from the complete separation of the
way tests of running test from driving and monitoring the test run
in CppUnit 2.
Those two activities are managed by two components: the TestRunner_ and
the TestDriver_.
While implementing a TestRunner_ is cheap, implementing TestDriver_ cost a lot,
especially if the test driver must provide a graphical user interface.
With Open Test, it is possible to reuse the existing TestDriver_ and
implement a TestRunner_ for a specific test framework. This makes
implementing a specific functional test framework cheap since you only need to
implement the testing part. All the monitoring, user interface parts are
already implemented and reusable.
.. _TestRunner:
What is a TestRunner?
=====================
A test runner is a lightweight component that provides the following
services:
* declare all the available tests
* run a specific list of tests and track the run of each test.
[Notes: need to be enhanced, resource acquisition service...]
.. _TestDriver:
What is a TestDriver?
=====================
A test driver as many responsibility:
* monitoring the test run and detecting crash and infinite-loop to resume
the test run.
* selecting the test(s) to run
* providing feedback during the test run (what test is being run, did the test
pass...)
* generating report of the test run (output result in XML, compiler and human
friendly text format...)
A test driver can usually be configured from both the command-line and a
configuration file for automated testing.
Graphical test drivers are provided for interactive browsing of the
test hierarchy, and visual feedback...
It should be noted that some test drivers could be connected to multiple
test runner at the same time.
How does the TestDriver communicate with the TestRunner?
========================================================
While it is possible for a TestDriver_ to directly call methods of a
TestRunner_, it is not the way it is usually done. Implementing reliable
test run monitoring requires running the test in a separate process.
Instead of going the easy way and using shared memory to share test data
structure, communication between the TestDriver_ and a TestRunner_ rely on
a duplex stream communication. While a little more complex to implement,
this have the great advantage that a TestDriver_ can be connected to
any TestRunner_ that implements the same protocol.
A TestDriver_ can communicate with a TestRunner_ that:
* is not using the same run-time version of the C library (a common issue
on the Windows platform)
* is not compiled using the same compiler
* is running on a different architecture (is a duplex network connection
is used)
* is possibly implemented using another language (would require porting
the communication layer to the alternate language)
..
Local Variables:
mode: indented-text
indent-tabs-mode: nil
sentence-end-double-space: t
fill-column: 70
End:
|