"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">\r
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">\r
<head>\r
-<link rel="icon" type="image/png" href="/favicon.png">\r
+<link rel="icon" type="image/x-icon" href="/favicon.ico">\r
<meta http-equiv="Content-Type" content="application/xhtml+xml; charset=UTF-8" />\r
<meta name="generator" content="AsciiDoc 8.6.9" />\r
<title>i3: i3 testsuite</title>\r
<ul id="nav">\r
<li><a style="border-bottom: 2px solid #fff" href="/docs">Docs</a></li>\r
<li><a href="/screenshots">Screens</a></li>\r
+ <li><a href="https://www.reddit.com/r/i3wm/">FAQ</a></li>\r
<li><a href="/contact">Contact</a></li>\r
- <li><a href="http://bugs.i3wm.org/">Bugs</a></li>\r
+ <li><a href="https://github.com/i3/i3/issues">Bugs</a></li>\r
</ul>\r
<br style="clear: both">\r
<div id="content">\r
client, simply called <tt>cpan</tt>. It comes with every Perl installation and can be\r
used to install the testsuite. Many users prefer to use the more modern\r
<tt>cpanminus</tt> instead, though (because it asks no questions and just works):</p></div>\r
+<div class="paragraph"><p>The tests additionally require <tt>Xephyr(1)</tt> to run a nested X server. Install\r
+<tt>xserver-xephyr</tt> on Debian or <tt>xorg-xserver-xephyr</tt> on Arch Linux.</p></div>\r
<div class="listingblock">\r
<div class="title">Installing testsuite dependencies using cpanminus (preferred)</div>\r
<div class="content">\r
with an appropriate configuration file and creates a folder for each run\r
containing the appropriate i3 logfile for each testcase. The latest folder can\r
always be found under the symlink <tt>latest/</tt>. Unless told differently, it will\r
-run the tests on a separate X server instance (using the Xdummy script).</p></div>\r
+run the tests on a separate X server instance (using Xephyr).</p></div>\r
+<div class="paragraph"><p>Xephyr will open a window where you can inspect the running test. You can run\r
+the tests without an X session with Xvfb, such as with <tt>xvfb-run\r
+./complete-run</tt>. This will also speed up the tests significantly especially on\r
+machines without a powerful video card.</p></div>\r
<div class="listingblock">\r
<div class="title">Example invocation of complete-run.pl+</div>\r
<div class="content">\r
<div class="paragraph"><p>If your attempt to run the tests with a bare call to ./complete-run.pl fails, try this:</p></div>\r
<div class="listingblock">\r
<div class="content">\r
-<pre><tt>$ ./complete-run.pl --parallel=1 --keep-xdummy-output</tt></pre>\r
+<pre><tt>$ ./complete-run.pl --parallel=1 --keep-xserver-output</tt></pre>\r
</div></div>\r
-<div class="paragraph"><p>One common cause of failures is not having the X dummy server module\r
-installed. Under Debian and Ubuntu this is the package\r
-<tt>xserver-xorg-video-dummy</tt>.</p></div>\r
+<div class="paragraph"><p>This will show the output of Xephyr, which is the X server implementation we\r
+use for testing.</p></div>\r
</div>\r
<div class="sect3">\r
-<h4 id="_ipc_interface">3.2.2. IPC interface</h4>\r
+<h4 id="_coverage_testing">3.2.2. Coverage testing</h4>\r
+<div class="paragraph"><p>Coverage testing is possible with <tt>lcov</tt>, the front-end for GCC’s coverage\r
+testing tool <tt>gcov</tt>. The testcases can generate a nice html report that tells\r
+you which functions and lines were covered during a run of the tests. You can\r
+use this tool to judge how effective your tests are.</p></div>\r
+<div class="paragraph"><p>To use test coverage tools, first compile with coverage enabled.</p></div>\r
+<div class="listingblock">\r
+<div class="content">\r
+<pre><tt>COVERAGE=1 make</tt></pre>\r
+</div></div>\r
+<div class="paragraph"><p>Then run the tests with the <tt>--coverage-testing</tt> flag.</p></div>\r
+<div class="listingblock">\r
+<div class="content">\r
+<pre><tt>./complete-run.pl --coverage-testing</tt></pre>\r
+</div></div>\r
+<div class="paragraph"><p>Then open <tt>latest/i3-coverage/index.html</tt> in your web browser.</p></div>\r
+</div>\r
+<div class="sect3">\r
+<h4 id="_ipc_interface">3.2.3. IPC interface</h4>\r
<div class="paragraph"><p>The testsuite makes extensive use of the IPC (Inter-Process Communication)\r
interface which i3 provides. It is used for the startup process of i3, for\r
terminating it cleanly and (most importantly) for modifying and getting the\r
<div class="paragraph"><p>See [<a href="http://i3wm.org/docs/ipc.html">http://i3wm.org/docs/ipc.html</a>] for documentation on the IPC interface.</p></div>\r
</div>\r
<div class="sect3">\r
-<h4 id="_x11_xcb">3.2.3. X11::XCB</h4>\r
+<h4 id="_x11_xcb">3.2.4. X11::XCB</h4>\r
<div class="paragraph"><p>In order to open new windows, change attributes, get events, etc., the\r
testsuite uses X11::XCB, a new (and quite specific to i3 at the moment) Perl\r
module which uses the XCB protocol description to generate Perl bindings to\r
X11. They work in a very similar way to libxcb (which i3 uses) and provide\r
-relatively high-level interfaces (objects such as <tt>X11::XCB::Window</tt>) aswell as\r
+relatively high-level interfaces (objects such as <tt>X11::XCB::Window</tt>) as well as\r
access to the low-level interface, which is very useful when testing a window\r
manager.</p></div>\r
</div>\r
<div class="sect2">\r
<h3 id="_filesystem_structure">3.3. Filesystem structure</h3>\r
<div class="paragraph"><p>In the git root of i3, the testcases live in the folder <tt>testcases</tt>. This\r
-folder contains the <tt>complete-run.pl</tt> and <tt>Xdummy</tt> scripts and a base\r
-configuration file which will be used for the tests. The different testcases\r
-(their file extension is .t, not .pl) themselves can be found in the\r
-conventionally named subfolder <tt>t</tt>:</p></div>\r
+folder contains the <tt>complete-run.pl</tt> and a base configuration file which will\r
+be used for the tests. The different testcases (their file extension is .t, not\r
+.pl) themselves can be found in the conventionally named subfolder <tt>t</tt>:</p></div>\r
<div class="listingblock">\r
<div class="title">Filesystem structure</div>\r
<div class="content">\r
│ │ ├── ...\r
│ │ ├── omitted for brevity\r
│ │ ├── ...\r
-│ │ └── 74-regress-focus-toggle.t\r
-│ └── Xdummy</tt></pre>\r
+│ │ └── 74-regress-focus-toggle.t</tt></pre>\r
</div></div>\r
</div>\r
</div>\r
cmd 'focus left';\r
is($x->input_focus, $left->id, 'left window focused');</tt></pre>\r
</div></div>\r
-<div class="paragraph"><p>However, the test fails. Sometimes. Apparantly, there is a race condition in\r
+<div class="paragraph"><p>However, the test fails. Sometimes. Apparently, there is a race condition in\r
your test. If you think about it, this is because you are using two different\r
pieces of software: You tell i3 to update focus, i3 confirms that, and then you\r
ask X11 to give you the current focus. There is a certain time i3 needs to\r
(72 files at the time of writing) from > 100 seconds to 16 seconds. This makes\r
it significantly more attractive to run the test suite more often (or at all)\r
during development.</p></div>\r
-<div class="paragraph"><p>An alternative approach to using socket activation is polling for the existance\r
+<div class="paragraph"><p>An alternative approach to using socket activation is polling for the existence\r
of the IPC socket and connecting to it. While this might be slightly easier to\r
implement, it wastes CPU time and is considerably uglier than this solution\r
:). After all, <tt>lib/SocketActivation.pm</tt> contains only 54 SLOC.</p></div>\r
projects / i3 / i3.github.io / blobdiff