95 lines
4.4 KiB
HTML
95 lines
4.4 KiB
HTML
<!DOCTYPE html>
|
|
<html>
|
|
<!-- Created by GNU Texinfo 7.1, https://www.gnu.org/software/texinfo/ -->
|
|
<head>
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
|
|
<!-- This manual documents Guile version 3.0.10.
|
|
|
|
Copyright (C) 1996-1997, 2000-2005, 2009-2023 Free Software Foundation,
|
|
Inc.
|
|
|
|
Copyright (C) 2021 Maxime Devos
|
|
|
|
Copyright (C) 2024 Tomas Volf
|
|
|
|
|
|
Permission is granted to copy, distribute and/or modify this document
|
|
under the terms of the GNU Free Documentation License, Version 1.3 or
|
|
any later version published by the Free Software Foundation; with no
|
|
Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
|
|
copy of the license is included in the section entitled "GNU Free
|
|
Documentation License." -->
|
|
<title>Testbed Example (Guile Reference Manual)</title>
|
|
|
|
<meta name="description" content="Testbed Example (Guile Reference Manual)">
|
|
<meta name="keywords" content="Testbed Example (Guile Reference Manual)">
|
|
<meta name="resource-type" content="document">
|
|
<meta name="distribution" content="global">
|
|
<meta name="Generator" content=".texi2any-real">
|
|
<meta name="viewport" content="width=device-width,initial-scale=1">
|
|
|
|
<link href="index.html" rel="start" title="Top">
|
|
<link href="Concept-Index.html" rel="index" title="Concept Index">
|
|
<link href="index.html#SEC_Contents" rel="contents" title="Table of Contents">
|
|
<link href="Programming-Overview.html" rel="up" title="Programming Overview">
|
|
<link href="Programming-Options.html" rel="next" title="Programming Options">
|
|
<link href="Scheme-vs-C.html" rel="prev" title="Scheme vs C">
|
|
<style type="text/css">
|
|
<!--
|
|
a.copiable-link {visibility: hidden; text-decoration: none; line-height: 0em}
|
|
span:hover a.copiable-link {visibility: visible}
|
|
-->
|
|
</style>
|
|
<link rel="stylesheet" type="text/css" href="https://www.gnu.org/software/gnulib/manual.css">
|
|
|
|
|
|
</head>
|
|
|
|
<body lang="en">
|
|
<div class="subsection-level-extent" id="Testbed-Example">
|
|
<div class="nav-panel">
|
|
<p>
|
|
Next: <a href="Programming-Options.html" accesskey="n" rel="next">A Choice of Programming Options</a>, Previous: <a href="Scheme-vs-C.html" accesskey="p" rel="prev">Why Scheme is More Hackable Than C</a>, Up: <a href="Programming-Overview.html" accesskey="u" rel="up">An Overview of Guile Programming</a> [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Concept-Index.html" title="Index" rel="index">Index</a>]</p>
|
|
</div>
|
|
<hr>
|
|
<h4 class="subsection" id="Example_003a-Using-Guile-for-an-Application-Testbed"><span>5.7.3 Example: Using Guile for an Application Testbed<a class="copiable-link" href="#Example_003a-Using-Guile-for-an-Application-Testbed"> ¶</a></span></h4>
|
|
|
|
<p>As an example of what this means in practice, imagine writing a testbed
|
|
for an application that is tested by submitting various requests (via a
|
|
C interface) and validating the output received. Suppose further that
|
|
the application keeps an idea of its current state, and that the
|
|
“correct” output for a given request may depend on the current
|
|
application state. A complete “white box”<a class="footnote" id="DOCF6" href="#FOOT6"><sup>6</sup></a> test plan for this application would aim to
|
|
submit all possible requests in each distinguishable state, and validate
|
|
the output for all request/state combinations.
|
|
</p>
|
|
<p>To write all this test code in C would be very tedious. Suppose instead
|
|
that the testbed code adds a single new C function, to submit an
|
|
arbitrary request and return the response, and then uses Guile to export
|
|
this function as a Scheme procedure. The rest of the testbed can then
|
|
be written in Scheme, and so benefits from all the advantages of
|
|
programming in Scheme that were described in the previous section.
|
|
</p>
|
|
<p>(In this particular example, there is an additional benefit of writing
|
|
most of the testbed in Scheme. A common problem for white box testing
|
|
is that mistakes and mistaken assumptions in the application under test
|
|
can easily be reproduced in the testbed code. It is more difficult to
|
|
copy mistakes like this when the testbed is written in a different
|
|
language from the application.)
|
|
</p>
|
|
|
|
</div>
|
|
<div class="footnotes-segment">
|
|
<hr>
|
|
<h4 class="footnotes-heading">Footnotes</h4>
|
|
|
|
<h5 class="footnote-body-heading"><a id="FOOT6" href="#DOCF6">(6)</a></h5>
|
|
<p>A <em class="dfn">white box</em>
|
|
test plan is one that incorporates knowledge of the internal design of
|
|
the application under test.</p>
|
|
</div>
|
|
|
|
|
|
|
|
</body>
|
|
</html>
|