115 lines
4.8 KiB
HTML
115 lines
4.8 KiB
HTML
<!DOCTYPE html>
|
||
<html>
|
||
<head>
|
||
<meta content="text/html; charset=utf-8" http-equiv="content-type">
|
||
<title>Programm Datenspuren 2016</title>
|
||
<link rel="stylesheet" media="screen" href="/2016/fahrplan/assets/public_schedule-fe5c2995f8fa4b0f51bd82df5c41e84e7e7c12485fe767c4a3cf56ad83b2844e.css">
|
||
<link rel="stylesheet" media="all" href="/2016/fahrplan/style.css">
|
||
<link rel="stylesheet" media="print" href="/2016/fahrplan/assets/public_schedule_print-99d3251f43ed74e6a77a8013f74ce1ee07c4de819a619a15d8b8bb5dc9d4dad1.css">
|
||
</head>
|
||
<body>
|
||
<div id="wrapper">
|
||
<div id="banner"></div>
|
||
<div id="header">
|
||
<h1>Programm Datenspuren 2016</h1>
|
||
</div>
|
||
<div id="navigation">
|
||
<ul>
|
||
<li>
|
||
<a href="/2016/fahrplan/schedule.html">Übersicht</a>
|
||
</li>
|
||
<li>
|
||
<a href="/2016/fahrplan/schedule/0.html">
|
||
Samstag
|
||
-
|
||
<span class="small-font">22.10.2016</span>
|
||
</a>
|
||
</li>
|
||
<li>
|
||
<a href="/2016/fahrplan/schedule/1.html">
|
||
Sonntag
|
||
-
|
||
<span class="small-font">23.10.2016</span>
|
||
</a>
|
||
</li>
|
||
<li>
|
||
<a href="/2016/fahrplan/speakers.html">Referenten</a>
|
||
</li>
|
||
<li class="selected">
|
||
<a href="/2016/fahrplan/events.html">Veranstaltungen</a>
|
||
</li>
|
||
<li>
|
||
<a href="/2016/fahrplan/qrcode.html">QR-Code</a>
|
||
</li>
|
||
</ul>
|
||
|
||
</div>
|
||
<div id="main-content">
|
||
<p class="release">
|
||
Version 0.6
|
||
</p>
|
||
<h2>Vortrag: Make your tests fail</h2>
|
||
<h3 class="title">How randomisation adds a whole new dimension to finding bugs in your code</h3>
|
||
<div class="column left" id="basic">
|
||
<div class="image large"><img src="/2016/fahrplan/assets/event_large-4b8aa978adbb7c8e80151f5a83c6782a12e763374ae3a042a55e7e626a64d93b.png" alt="Event large"></div>
|
||
<p class="abstract">It's easy as pie: before checking in, your test suite should always be green. Or should it? What if your tests are all green but you forgot to check one important edge case? What if your underlying system environment lets you down, but only under rare conditions that you didn't cover in your tests?
|
||
</p>
|
||
<p class="description">This talk introduces randomised testing as used by projects like Apache Lucene and Elasticsearch based on the Carrotsearch Randomised Testing framework. It has helped uncover (and ultimately fix) a huge number of bugs not only in these project’s source code, but also in the JVM itself which those projects rely on.</p>
|
||
|
||
<p class="description">Writing unit and integration tests can be tricky: assumptions about your code may not always be true as any number of "this should never happen" log entries in production systems show. When implementing a system that will be integrated in all sorts of expected, unexpected, and outright weird ways by downstream users, testing all possible code paths, configurations and deployment environments gets complicated.</p>
|
||
|
||
<p class="description">With the Carrotsearch Randomised Testing framework, projects like Apache Lucene and Elasticsearch have introduced a new level to their unit and integration tests. Input values are no longer statically pre-defined but are generated based on developer defined constraints, meaning The test suite is no longer re-run with a static set of input data each time. Instead, every continuous integration run adds to the search space covered. Though generated at random, tests are still reproducible as all configurations are based on specific test seeds that can be used to re-run the test with the exact same configuration.</p>
|
||
|
||
<p class="description">Add to this randomising the runtime environment by executing tests with various JVM versions and configurations,and you are bound to find cases where your application runs into limitations and bugs in the JVM.</p>
|
||
|
||
<p class="description">This talk introduces randomised testing as a concept, shows examples of how the Carrotsearch Randomised Testing framework helps with making your test cases more interesting, and provides some insight into how randomising your execution environment can help save downstream users from surprises. All without putting too much strain on your continuous integration resources.</p>
|
||
</div>
|
||
<div class="column left" id="details">
|
||
<h3>Info</h3>
|
||
<p>
|
||
<b>Tag:</b>
|
||
<a href="/2016/fahrplan/schedule/0.html">22.10.2016</a>
|
||
<br>
|
||
<b>Anfang:</b>
|
||
15:00 Uhr
|
||
<br>
|
||
<b>Dauer:</b>
|
||
00:45
|
||
<br>
|
||
<b>Raum:</b>
|
||
Kino
|
||
<br>
|
||
<br>
|
||
<b>Sprache:</b>
|
||
|
||
</p>
|
||
<h3>Links:</h3>
|
||
<ul>
|
||
<li><a href="/2016/fahrplan/events/7745.ics">iCalendar</a></li>
|
||
</ul>
|
||
<div class="column left" id="concurrent_events">
|
||
<h3><span class="translation_missing" title="translation missing: de.public.schedule.event.concurrent_events">Concurrent Events</span></h3>
|
||
<dl class="dl-horizontal">
|
||
</dl>
|
||
</div>
|
||
</div>
|
||
<div class="column right" id="sidebar">
|
||
<h3>Referenten</h3>
|
||
<table class="list">
|
||
<tbody>
|
||
<tr>
|
||
<td><div class="image small"><img src="/2016/fahrplan/system/people/avatars/000/006/573/small/isabel.jpg" alt="Isabel"></div></td>
|
||
<td><a href="/2016/fahrplan/speakers/6573.html">Isabel Drost-Fromm</a></td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</div>
|
||
<div class="span16">
|
||
</div>
|
||
|
||
<br class="clear">
|
||
</div>
|
||
</div>
|
||
</body>
|
||
</html>
|