Skip to content

Latest commit

 

History

History
executable file
·
222 lines (220 loc) · 16.8 KB

index.html

File metadata and controls

executable file
·
222 lines (220 loc) · 16.8 KB
 
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
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/xhtml;charset=UTF-8"/>
<meta http-equiv="X-UA-Compatible" content="IE=9"/>
<meta name="generator" content="Doxygen 1.8.4"/>
<title>SDL Visual Test: Visual and Interactive Test Automation for SDL 2.0</title>
<link href="tabs.css" rel="stylesheet" type="text/css"/>
<script type="text/javascript" src="jquery.js"></script>
<script type="text/javascript" src="dynsections.js"></script>
<link href="search/search.css" rel="stylesheet" type="text/css"/>
<script type="text/javascript" src="search/search.js"></script>
<script type="text/javascript">
$(document).ready(function() { searchBox.OnSelectItem(0); });
</script>
<link href="doxygen.css" rel="stylesheet" type="text/css" />
</head>
<body>
<div id="top"><!-- do not remove this div, it is closed by doxygen! -->
<div id="titlearea">
<table cellspacing="0" cellpadding="0">
<tbody>
<tr style="height: 56px;">
<td style="padding-left: 0.5em;">
<div id="projectname">SDL Visual Test
</div>
</td>
</tr>
</tbody>
</table>
</div>
<!-- end header part -->
<!-- Generated by Doxygen 1.8.4 -->
<script type="text/javascript">
var searchBox = new SearchBox("searchBox", "search",false,'Search');
</script>
<div id="navrow1" class="tabs">
<ul class="tablist">
<li class="current"><a href="index.html"><span>Main&#160;Page</span></a></li>
<li><a href="annotated.html"><span>Data&#160;Structures</span></a></li>
<li><a href="files.html"><span>Files</span></a></li>
<li>
<div id="MSearchBox" class="MSearchBoxInactive">
<span class="left">
<img id="MSearchSelect" src="search/mag_sel.png"
onmouseover="return searchBox.OnSearchSelectShow()"
onmouseout="return searchBox.OnSearchSelectHide()"
alt=""/>
<input type="text" id="MSearchField" value="Search" accesskey="S"
onfocus="searchBox.OnSearchFieldFocus(true)"
onblur="searchBox.OnSearchFieldFocus(false)"
onkeyup="searchBox.OnSearchFieldChange(event)"/>
</span><span class="right">
<a id="MSearchClose" href="javascript:searchBox.CloseResultsWindow()"><img id="MSearchCloseImg" border="0" src="search/close.png" alt=""/></a>
</span>
</div>
</li>
</ul>
</div>
</div><!-- top -->
<!-- window showing the filter options -->
<div id="MSearchSelectWindow"
onmouseover="return searchBox.OnSearchSelectShow()"
onmouseout="return searchBox.OnSearchSelectHide()"
onkeydown="return searchBox.OnSearchSelectKey(event)">
<a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(0)"><span class="SelectionMark">&#160;</span>All</a><a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(1)"><span class="SelectionMark">&#160;</span>Data Structures</a><a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(2)"><span class="SelectionMark">&#160;</span>Files</a><a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(3)"><span class="SelectionMark">&#160;</span>Functions</a><a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(4)"><span class="SelectionMark">&#160;</span>Variables</a><a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(5)"><span class="SelectionMark">&#160;</span>Typedefs</a><a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(6)"><span class="SelectionMark">&#160;</span>Enumerations</a><a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(7)"><span class="SelectionMark">&#160;</span>Enumerator</a><a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(8)"><span class="SelectionMark">&#160;</span>Macros</a><a class="SelectItem" href="javascript:void(0)" onclick="searchBox.OnSelectItem(9)"><span class="SelectionMark">&#160;</span>Pages</a></div>
<!-- iframe showing the search results (closed by default) -->
<div id="MSearchResultsWindow">
<iframe src="javascript:void(0)" frameborder="0"
name="MSearchResults" id="MSearchResults">
</iframe>
</div>
<div class="header">
<div class="headertitle">
<div class="title">Visual and Interactive Test Automation for SDL 2.0 </div> </div>
</div><!--header-->
<div class="contents">
<div class="textblock"><h1><a class="anchor" id="license_sec"></a>
License</h1>
<p>Check the file <code>COPYING.txt</code> for licensing information.</p>
<h1><a class="anchor" id="intro_sec"></a>
Introduction</h1>
<p>The goal of this GSoC project is to automate the testing of testsprite2. testsprite2 takes 26 parameters which have thousands of valid combinations and is used to validate SDL's window, mouse and rendering behaviour. By having a test harness that runs testsprite2 with various command line argument strings and validates the output for each run, we can make testing an easier task for maintainers, contributors and testers. The test harness can be used by a continuous integration system (like buildbot or jenkins) to validate SDL after checkins.</p>
<p>SDL Homepage: <a href="http://libsdl.org/">http://libsdl.org/</a></p>
<h1><a class="anchor" id="build_sec"></a>
Building</h1>
<h2><a class="anchor" id="build_linux"></a>
Building on Linux/Cygwin</h2>
<p><code>./autogen.sh; ./configure; make;</code></p>
<h2><a class="anchor" id="build_windows"></a>
Building on Windows</h2>
<p>Use the Visual Studio solution under <code>SDL/VisualC/visualtest</code>.</p>
<h1><a class="anchor" id="docs_sec"></a>
Documentation</h1>
<p>Documentation is available via Doxygen. To build the documentation, cd to the SDL/visualtest/docs directory and run <code>doxygen</code>. A good starting point for exploring the documentation is <code>SDL/visualtest/docs/html/index.html</code> </p>
<h1><a class="anchor" id="usage_sec"></a>
Usage</h1>
<p>To see all the options supported by the test harness, just run <code>testharness</code> with no arguments.</p>
<p>At the moment the following options are supported: </p>
<ul>
<li><code>sutapp</code> - Path to the system under test (SUT) application </li>
<li><code>sutargs</code> - Launch the SUT with the specified arguments string </li>
<li><code>timeout</code> - The maximum time after which the SUT process will be killed; passed as hh:mm:ss; default 00:01:00 </li>
<li><code>variator</code> - Which variator to use; see <a class="el" href="index.html#variators_sec">Variators</a> </li>
<li><code>num-variations</code> - The number of variations to run for; taken to be 1 for the random variator and ALL for the exhaustive variator by default </li>
<li><code>no-launch</code> - Just print the arguments string for each variation without launching the SUT or performing any actions </li>
<li><code>parameter-config</code> - A config file that describes the command line parameters supported by the SUT; see <a class="el" href="index.html#paramconfig_sec">The SUT Parameters File</a> or the sample *.parameters files for more details </li>
<li><code>action-config</code> - A config file with a list of actions to be performed while the SUT is running; see <a class="el" href="index.html#actionconfig_sec">The Actions File</a> or the sample *.actions files </li>
<li><code>output-dir</code> - Path to the directory where screenshots should be saved; is created if it doesn't exist; taken to be "./output" by default </li>
<li><code>verify-dir</code> - Path to the directory with the verification images; taken to be "./verify" by default</li>
</ul>
<p>Paths can be relative or absolute.</p>
<p>Alternatively, the options can be passed as a config file for convenience:</p>
<p><code>testharness --config testsprite2_sample.config</code></p>
<p>For a sample, take a look at the *.config files in this repository.</p>
<p>We can also pass a config file and override certain options as necessary: <code>testharness --config testsprite2_sample.config --num-variations 10</code></p>
<p>Note: You may find it convenient to copy the SUT executable along with any resources to the test harness directory. Also note that testsprite2 and its resources (icon.bmp) are automatically copied when using the Visual Studio solution.</p>
<h2><a class="anchor" id="usageexamples_subsec"></a>
Usage examples:</h2>
<p>Passing a custom arguments string: <code>testharness --sutapp testsprite2 --sutargs "\-\-cyclecolor \-\-blend mod
\-\-iterations 2" --action-config xyz.actions</code></p>
<p>Using the random variator: <code>testharness --sutapp testsprite2 --variator random --num-variations 5 --parameter-config xyz.parameters --action-config xyz.actions</code></p>
<h2><a class="anchor" id="config_subsec"></a>
Config Files</h2>
<p>Config files are an alternate way to pass parameters to the test harness. We describe the paramters in a config file and pass that to the test harness using the --config option. The config file consists of lines of the form "x=y" where x is an option and y is it's value. For boolean options, we simply give the name of the option to indicate that it is to be passed to the testharness.</p>
<p>The hash '#' character can be used to start a comment from that point to the end of the line.</p>
<h1><a class="anchor" id="paramconfig_sec"></a>
The SUT Parameters File</h1>
<p>To generate variations we need to describe the parameters the will be passed to the SUT. This description is given in a parameters file. Each line of the parameters file (except the blank lines) represents one command line option with five comma separated fields: <code>name, type, values, required, categories</code></p>
<ul>
<li><code>name</code> is the name of the option, e.g., <code>--cyclecolor</code>. </li>
<li><code>type</code> can have one of three values - integer, boolean and enum. </li>
<li><code>values</code> - for integer options this is the valid range of values the option can take, i.e., [min max]. For enum options this is a list of strings that the option can take, e.g., [val1 val2 val3]. For boolean options this field is ignored. </li>
<li><code>required</code> - true if the option is required, false otherwise. </li>
<li><code>categories</code> - a list of categories that the option belongs to. For example, [video mouse audio]</li>
</ul>
<p>Just like with config files, hash characters can be used to start comments.</p>
<h2><a class="anchor" id="additionalnotes_subsec"></a>
Additional Notes</h2>
<ul>
<li>If you want to have an option that always takes a certain value, use an enum with only one value. </li>
<li>Currently there isn't any way to turn an option off, i.e., all options will be included in the command line options string that is generated using the config. If you don't want an option to be passed to the SUT, remove it from the config file or comment it out.</li>
</ul>
<h1><a class="anchor" id="variators_sec"></a>
Variators</h1>
<p>Variators are the mechanism by which we generate strings of command line arguments to test the SUT with. A variator is quite simply an iterator that iterates through different variations of command line options. There are two variators supported at the moment: </p>
<ul>
<li><b>Exhaustive</b> - Generate all possible combinations of command line arguments that are valid. </li>
<li><b>Random</b> - Generate a random variation each time the variator is called.</li>
</ul>
<p>As an example, let's try a simple .parameters file:<br/>
<code> --blend, enum, [add mod], false, [] <br/>
--fullscreen, boolean, [], false, [] </code></p>
<p>The exhaustive variator would generate the following four variations:<br/>
<code> --blend add <br/>
--blend mod <br/>
--blend add --fullscreen <br/>
--blend mod --fullscreen <br/>
</code></p>
<p>The random variator would simply generate a random variation like the following:<br/>
<code>--blend mod</code></p>
<h1><a class="anchor" id="actionconfig_sec"></a>
The Actions File</h1>
<p>Once the SUT process has been launched, automated testing happens using a mechanism called actions. A list of actions is read from a file and each action is performed on the SUT process sequentially. Each line in the actions file describes an action. The format for an action is <code>hh:mm:ss ACTION_NAME additional parameters</code>. There are five actions supported at the moment: </p>
<ul>
<li><b>SCREENSHOT</b> - Takes a screenshot of each window owned by the SUT process. The images are saved as <code></code>[hash]_[i].bmp where <code></code>[hash] is the 32 character long hexadecimal MD5 hash of the arguments string that was passed to the SUT while launching it and <code>i</code> is the window number. i = 1 is an exceptional case where the <code>_</code>[i] is dropped and the filename is simply <code></code>[hash].bmp<br/>
Note: The screenshots are only of the window's client area. </li>
<li><b>VERIFY</b> - Verifies the screenshots taken by the last SCREENSHOT action by comparing them against a verification image. Each <code></code>[hash]_i.bmp image output by the SCREENSHOT action is compared against a <code></code>[hash].bmp image in the verify-dir. </li>
<li><b>QUIT</b> - Gracefully quits the SUT process. On Windows this means sending a WM_CLOSE message to each window owned by the SUT process. On Linux it means sending a SIGQUIT signal to the SUT process. </li>
<li><b>KILL</b> - Forcefully kills the SUT process. This is useful when the SUT process doesn't respond to the QUIT action. </li>
<li><b>LAUNCH [/path/to/executable] [args]</b> - Runs an executable with <code></code>[args] as the arguments string.</li>
</ul>
<p>Just like with config files, hash characters can be used to start comments.</p>
<h1><a class="anchor" id="contint_sec"></a>
Continuous Integration (CI)</h1>
<p>One of the goals of the project was to create a test harness that integrates with CI systems to provide automated visual and interactive testing to SDL.</p>
<p>At the moment the test harness can be run in two modes that are useful for CI: </p>
<ul>
<li>Crash testing mode - launch the SUT with every variation and all parameters, report to the CI if there's a crash </li>
<li>Visual testing mode - launch and visually verify the SUT for a smaller subset of the parameters</li>
</ul>
<p>Look at the launch_harness.sh/launch_harness.cmd for an example scripts that run the test harness for all variations with all parameters and report an error on a crash. The script uses the testsprite2_crashtest config, so remember to copy those files over to the test harness executable directory along with the script.</p>
<h1><a class="anchor" id="todo_sec"></a>
TODOs</h1>
<ul>
<li>Allow specifying a clipping box along with the VERIFY action, i.e., hh:mm:ss VERIFY x, y, w, h </li>
<li>Add support for spaces between the equals sign in test harness config files </li>
<li>Implement the SCREENSHOT action on Linux </li>
<li>Add a pairwise variator </li>
<li>Add actions to inject keyboard/mouse events </li>
<li>Add actions to manipulate the SUT window, e.g., minimize, restore, resize </li>
<li>Add support to load and save screenshots as .pngs instead of .bmps</li>
</ul>
<h1><a class="anchor" id="issues_sec"></a>
Known Issues</h1>
<ul>
<li>The QUIT action does not work on a testsprite2 process with multiple windows. This appears to be an issue with testsprite2. </li>
<li>The SCREENSHOT action doesn't capture the testsprite2 window correctly if the &ndash;fullscreen option is supplied. It works with &ndash;fullscreen-desktop, however.</li>
</ul>
<h1><a class="anchor" id="moreinfo_sec"></a>
More Information</h1>
<p>Author Contact Info:<br/>
Apoorv Upreti <code>&lt;<a href="#" onclick="location.href='mai'+'lto:'+'apo'+'or'+'vup'+'re'+'ti@'+'gm'+'ail'+'.c'+'om'; return false;">apoor<span style="display: none;">.nosp@m.</span>vupr<span style="display: none;">.nosp@m.</span>eti@g<span style="display: none;">.nosp@m.</span>mail<span style="display: none;">.nosp@m.</span>.com</a>&gt;</code> </p>
<p>Other useful links:</p>
<ul>
<li>Project Repository: <a href="https://bitbucket.org/nerdap/sdlvisualtest">https://bitbucket.org/nerdap/sdlvisualtest</a></li>
<li>Project Wiki: <a href="https://github.com/nerdap/autotestsprite2/wiki">https://github.com/nerdap/autotestsprite2/wiki</a></li>
<li>Project Blog: <a href="http://nerdap.github.io">http://nerdap.github.io</a></li>
<li>Verification images for testsprite2_blendmodes: <a href="https://www.dropbox.com/s/nm02aem76m812ng/testsprite2_blendmodes.zip">https://www.dropbox.com/s/nm02aem76m812ng/testsprite2_blendmodes.zip</a></li>
<li>Verification images for testsprite2_geometry: <a href="https://www.dropbox.com/s/csypwryopaslpaf/testsprite2_geometry.zip">https://www.dropbox.com/s/csypwryopaslpaf/testsprite2_geometry.zip</a> </li>
</ul>
</div></div><!-- contents -->
<!-- start footer part -->
<hr class="footer"/><address class="footer"><small>
Generated on Thu Sep 26 2013 00:18:24 for SDL Visual Test by &#160;<a href="http://www.doxygen.org/index.html">
<img class="footer" src="doxygen.png" alt="doxygen"/>
</a> 1.8.4
</small></address>
</body>
</html>