RubyGems - qed - Versions diffs - 2.1.1 → 2.2.0 - Mend

qed 2.1.1 → 2.2.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (67) hide show

data/COPYING +622 -344
data/DIARY.rdoc +117 -0
data/HISTORY +36 -0
data/PROFILE +16 -0
data/README.rdoc +69 -36
data/REQUIRE +9 -0
data/ROADMAP +12 -0
data/VERSION +5 -0
data/demo/01_demos.rdoc +56 -0
data/demo/02_advice.rdoc +158 -0
data/demo/03_helpers.rdoc +42 -0
data/demo/04_fixtures.rdoc +29 -0
data/demo/05_quote.rdoc +24 -0
data/demo/07_toplevel.rdoc +42 -0
data/demo/08_cross_script.rdoc +27 -0
data/demo/09_cross_script.rdoc +27 -0
data/demo/10_constant_lookup.rdoc +16 -0
data/demo/applique/constant.rb +2 -0
data/demo/applique/env.rb +5 -0
data/demo/applique/fileutils.rb +1 -0
data/demo/applique/markup.rb +10 -0
data/demo/applique/quote.rb +4 -0
data/demo/applique/toplevel.rb +15 -0
data/demo/fixtures/data.txt +1 -0
data/demo/fixtures/table.yml +5 -0
data/demo/helpers/advice.rb +40 -0
data/demo/helpers/sample.rb +4 -0
data/demo/helpers/toplevel.rb +6 -0
data/eg/hello_world.rdoc +15 -0
data/{demo/error.rdoc → eg/view_error.rdoc} +0 -0
data/{demo → eg}/website.rdoc +0 -0
data/lib/qed.rb +20 -1
data/lib/qed/advice.rb +4 -30
data/lib/qed/advice/events.rb +6 -3
data/lib/qed/advice/patterns.rb +37 -19
data/lib/qed/applique.rb +85 -0
data/lib/qed/command.rb +3 -5
data/lib/qed/evaluator.rb +52 -56
data/lib/qed/package.yml +5 -0
data/lib/qed/parser.rb +149 -0
data/lib/qed/profile.yml +16 -0
data/lib/qed/reporter/{base.rb → abstract.rb} +17 -19
data/lib/qed/reporter/bullet.rb +14 -16
data/lib/qed/reporter/dotprogress.rb +7 -6
data/lib/qed/reporter/html.rb +21 -3
data/lib/qed/reporter/verbatim.rb +28 -26
data/lib/qed/scope.rb +98 -82
data/lib/qed/script.rb +21 -69
data/lib/qed/session.rb +44 -3
data/script/qedoc +2 -0
data/script/test +2 -0
metadata +74 -28
data/doc/qedoc/index.html +0 -515
data/doc/qedoc/jquery.js +0 -19
data/meta/authors +0 -1
data/meta/created +0 -1
data/meta/description +0 -2
data/meta/homepage +0 -1
data/meta/name +0 -1
data/meta/released +0 -1
data/meta/repository +0 -1
data/meta/requires +0 -5
data/meta/ruby +0 -2
data/meta/suite +0 -1
data/meta/summary +0 -1
data/meta/title +0 -1
data/meta/version +0 -1

data/doc/qedoc/index.html DELETED Viewed

@@ -1,515 +0,0 @@
-<html>
-<head>
-  <title>QED Demonstrandum</title>
-  <style>
-    #container{ margin: 0 auto; width: 800px; }
-    /* Debug borders */
-    /* p, li, dt, dd, div, pre, h1, h2, h3, h4, h5, h6 { border: 1px solid red; } */
-    body { font-size: 14px; line-height: 20px; margin: 1em 5% 1em 5%; font-family: Verdana, Arial, Helvetica, sans-serif; }
-    a { color: #336; text-decoration: underline; }
-    a:visited { color: #334; }
-    em { font-style: italic; }
-    strong { font-weight: bold; }
-    tt { color: navy; }
-    h1, h2, h3, h4, h5, h6 { color: #223; margin-top: 1.2em; margin-bottom: 0.5em; line-height: 1.3; }
-    h1 { border-bottom: 2px solid silver; }
-    h2 { border-bottom: 2px solid silver; padding-top: 0.5em; }
-    hr { color: #ccc; margin-top: 1.6em; }
-    p { color: #222; text-align: justify; margin-top: 0.5em; margin-bottom: 0.5em; line-height: 1.4em; }
-    pre { padding: 10; margin: 0; font-family: monospace; font-size: 0.9em; }
-    pre.pass { color: green; }
-    pre.fail { color: red; }
-    pre.error { color: red; font-weight: bold; }
-    span#author { color: #527bbd; font-weight: bold; font-size: 1.1em; }
-    span#email { }
-    span#revision { }
-    div#footer { font-size: small; border-top: 2px solid silver; padding-top: 0.5em; margin-top: 4.0em; }
-    div#footer-text { float: left; padding-bottom: 0.5em; }
-    div#footer-badges { float: right; padding-bottom: 0.5em; }
-    /* Block element content. */
-    div.content { padding: 0; }
-    /* Block element titles. */
-    h1.title { font-weight: bold; text-align: left; font-size: 3em; margin-top: 1.0em; margin-bottom: 0.5em; }
-    /* Block element titles. */
-    div.title, caption.title { font-weight: bold; text-align: left; margin-top: 1.0em; margin-bottom: 0.5em; }
-    div.title + * { margin-top: 0; }
-    td div.title:first-child { margin-top: 0.0em; }
-    div.content div.title:first-child { margin-top: 0.0em; }
-    div.content + div.title { margin-top: 0.0em; }
-    div.sidebarblock > div.content { background: #ffffee; border: 1px solid silver; padding: 0.5em; }
-    img { border-style: none; }
-    dl { margin-top: 0.8em; margin-bottom: 0.8em; }
-    dt { margin-top: 0.5em; margin-bottom: 0; font-style: italic; }
-    dd > *:first-child { margin-top: 0; }
-    ul, ol { list-style-position: outside; }
-    thead { font-weight: bold; }
-    tfoot { font-weight: bold; }
-  </style>
-  <!-- TODO: only include if these files exists -->
-  <link href="../assets/styles/spec.css" type="text/css" rel="stylesheet">
-  <!-- spec.css might be a problem with clobber -->
-  <link href="spec.css" type="text/css" rel="stylesheet">
-  <!-- JQuery is needed -->
-  <script src="jquery.js" type="text/javascript" language="javascript"></script>
-</head>
-<body>
-  <!-- Side Table of Contents -->
-  <div id="sidebar" style="position: fixed; top: 10; right: 10; background: white;">
-    <a href="javascript: toc_toggle();">
-      <img src="img/icon/book.jpg" height="30px;" style="border: none;" alt="TOC" align="right"/>
-    </a>
-    <div id="toc_side" class="toc">
-    </div>
-  </div>
-  <div id="container">
-    <div id="header">
-      <img src="img/icon/book.jpg" align="left" style="padding-right: 10px;" alt=""/>
-      <h1 class="title">QED Demonstrandum</h1>
-      <h1>Table of Contents</h1>
-      <div class="toc">
-      </div>
-    </div>
-    <div id="content">
-      <body>
-<h1>Demonstrations</h1>
-<h2>Standard Sections</h2>
-<p>
-QED demos are light-weight specification documents, highly suitable to
-interface-driven design. The documents are divided up into clauses
-separated by blank lines. Clauses that are flush to the left margin are
-always explanation or comment clauses. Indented clauses are always
-executable code.
-</p>
-<p>
-Each code section is executed in order of appearance, within a rescue
-wrapper that captures any failures or errors. If neither a failure or error
-occur then the code gets a “pass”.
-</p>
-<p>
-For example, the following passes:
-</p>
-<pre>
-    (2 + 2).assert == 4
-</pre>
-<p>
-While the following would “fail”, as indicated by the raising
-of an Assertion error:
-</p>
-<pre>
-    expect Assertion do
-      (2 + 2).assert == 5
-    end
-</pre>
-<p>
-And this would have raised a NameError:
-</p>
-<pre>
-    expect NameError do
-      nobody_knows_method
-    end
-</pre>
-<h2>Neutral Code Blocks</h2>
-<p>
-There is no means of specifying that a code clause is neutral code, i.e.
-that it should be executed but not tested. Thus far, such a feature has
-proven to be a YAGNI.
-</p>
-<h2>Defining Custom Assertions</h2>
-<p>
-The context in which the QED code is run is a self-extended module, thus
-reusable macros can be created simply by defining a method.
-</p>
-<pre>
-    def assert_integer(x)
-      x.assert.is_a? Integer
-    end
-</pre>
-<p>
-Now lets try out our new macro definition.
-</p>
-<pre>
-    assert_integer(4)
-</pre>
-<p>
-Let’s prove that it can also fail:
-</p>
-<pre>
-    expect Assertion do
-      assert_integer("IV")
-    end
-</pre>
-</body>
-<body>
-<h1>Advice</h1>
-<p>
-Advice are wrapper methods that augment demonstrations. They are used to
-keep demonstrations clean of extraneous, repetitive and merely
-adminstrative code that the reader does not need to see over and over.
-</p>
-<h2>Before and After</h2>
-<p>
-QED supports <b>before</b> and <b>after</b> clauses in a specification
-through the use of Before and After code blocks. These blocks are executed
-at the beginning and at the end of each indicated step.
-</p>
-<p>
-We use a <b>before</b> clause if we want to setup some code at the start of
-each code step.
-</p>
-<pre>
-    a, z = nil, nil
-    Before do
-      a = "BEFORE"
-    end
-</pre>
-<p>
-And an <b>after</b> clause to teardown objects after a code step.
-</p>
-<pre>
-    After do
-      z = "AFTER"
-    end
-</pre>
-<p>
-Notice we assigned <tt>a</tt> and <tt>z</tt> before the block. This was to
-ensure their visibility in the scope later. Now, lets verify that the
-<b>before</b> and <b>after</b> clauses work.
-</p>
-<pre>
-    a.assert == "BEFORE"
-    a = "A"
-    z = "Z"
-</pre>
-<p>
-And now.
-</p>
-<pre>
-    z.assert == "AFTER"
-</pre>
-<p>
-There can be more than one before and after clause at a time. If we define
-a new <b>before</b> or <b>after</b> clause later in the document, it will
-be appended to the current list of clauses in use.
-</p>
-<p>
-As a demonstration of this:
-</p>
-<pre>
-    b = nil
-    Before do
-      b = "BEFORE AGAIN"
-    end
-</pre>
-<p>
-We will see it is the case.
-</p>
-<pre>
-    b.assert == "BEFORE AGAIN"
-</pre>
-<p>
-Only use <b>before</b> and <b>after</b> clauses when necessary
-—specifications are generally more readable without them. Indeed,
-some developers make a policy of avoiding them altogether. YMMV.
-</p>
-<h2>Caveats of Before and After</h2>
-<p>
-Instead of using Before and After clauses, it is wiser to define a reusable
-setup method. For example, in the helper if we define a method such as
-#prepare_example.
-</p>
-<pre>
-  def prepare_example
-    "Hello, World!"
-  end
-</pre>
-<p>
-Then we can reuse it in later code blocks.
-</p>
-<pre>
-  example = prepare_example
-  example.assert == "Hello, World!"
-</pre>
-<p>
-The advantage to this is that it gives the reader an indication of what is
-going on behind the scenes, rather the having an object just magically
-appear.
-</p>
-<h2>Event Targets</h2>
-<p>
-There is a small set of advice targets that do not come before or after an
-event, rather they occur <b>upon</b> a particular event. These include
-<tt>:load</tt> and <tt>:unload</tt>, for when a new helper is loaded;
-<tt>:pass</tt>, <tt>:fail</tt> and <tt>:error</tt> for when a code block
-passes, fails or raises an error; and <tt>:tag</tt> which is a low-level
-target triggered upon parsing each element in the HTML conversion of the
-demonstration.
-</p>
-<p>
-These event targets can be advised by calling the <tt>When</tt> method with
-the target type as an argument along with the code block to be run when the
-event is triggered.
-</p>
-<pre>
-  x = []
-  When(:tag) do |element|
-    x &lt;&lt; element.text.strip if element.name == 'li'
-  end
-</pre>
-<p>
-Not let see it is worked:
-</p>
-<ul>
-<li>SampleA
-</li>
-<li>SampleB
-</li>
-<li>SampleC
-</li>
-</ul>
-<p>
-So <tt>x</tt> should now contain these three list samples.
-</p>
-<pre>
-  x.assert == [ 'SampleA', 'SampleB', 'SampleC' ]
-</pre>
-<h2>Pattern Matchers</h2>
-<p>
-QED also supports comment match triggers. With the <tt>When</tt> method one
-can define procedures to run when a given pattern matches comment text. For
-example:
-</p>
-<pre>
-    When 'given a setting @a equal to (((\d+)))' do |n|
-      @a = n.to_i
-    end
-</pre>
-<p>
-Now, @a will be set to 1 whenever a comment like this one contains,
-“given a setting @a equal to 1”.
-</p>
-<pre>
-    @a.assert == 1
-</pre>
-<p>
-A string pattern is translated into a regular expression. In fact, you can
-use a regular expression if you need more control over the match. When
-using a string all spaces are converted to <tt>\s+</tt> and anything within
-double-parenthesis is treated as raw regular expression. Since the above
-example has (((\d+))), the actual regular expression contains
-<tt>(\d+)</tt>, so any number can be used. For example, “given a
-setting @a equal to 2”.
-</p>
-<pre>
-    @a.assert == 2
-</pre>
-<p>
-Typically you will want to put triggers is helper files, rather then place
-them directly in the demonstration document.
-</p>
-<p>
-This concludes the basic overview of QED’s specification system,
-which is itself a QED document. Yes, we eat our own dog food.
-</p>
-</body>
-<body>
-<h1>Helpers</h1>
-<p>
-There are two ways to load advice scripts. Either per demonstration or
-globally. Per demonstration helpers apply only to the current
-demonstration. Global helpers apply to all demonstrations.
-</p>
-<h2>Global Helpers</h2>
-<p>
-Global helpers are loaded at the start of a session and apply equally to
-all demonstrations in a suite.
-</p>
-<h2>Local Helpers</h2>
-<p>
-Helper scripts can be written just a demonstration scripts, or they can be
-defined as pure Ruby scripts. Either way they are loaded per-demonstration
-by using specially marked links.
-</p>
-<p>
-For example, because this link, <a href="qed://helpers/advice.rb">Advice</a>, begins with <tt>require:</tt>,
-it will be used to load a global helper. We can see this with the
-following:
-</p>
-<pre>
-  pudding.assert.include?('load advice.rb')
-</pre>
-<p>
-No where in the demonstration have we defined <tt>pudding</tt>, but it has
-been defined for us in the advice.rb helper script.
-</p>
-<p>
-We can also see that the generic When clause in our advice helper is
-keeping count of descriptions. Since the helper script was loaded three
-paragraphs back, the count will be 3.
-</p>
-<pre>
-  count.assert == 3
-</pre>
-<p>
-Helpers are vital to building test-demonstration suites for applications.
-But here again, only use them as necessary. The more helpers you use the
-more difficult your demos will be to follow.
-</p>
-</body>
-<body>
-<h1>Fixtures</h1>
-<h2>Flat-file Data</h2>
-<p>
-When creating testable demonstrations, there are times when sizable chunks
-of data are needed. It is convenient to store such data in separate files.
-The <tt>Data</tt> method makes is easy to load such files.
-</p>
-<pre>
-    Data('fixtures/data.txt').assert =~ /dolor/
-</pre>
-<p>
-All files are found relative to the location of current document.
-</p>
-<h2>Tabular Data</h2>
-<p>
-The <tt>Table</tt> method is similar to the <tt>Data</tt> method except
-that it expects a YAML file, and it can take a block to iterate the data
-over. This makes it easy to test tables of examples.
-</p>
-<p>
-The arity of the table block corresponds to the number of columns in each
-row of the table. Each row is assigned in turn and run through the coded
-step. Consider the following example:
-</p>
-<p>
-Every row in the <a href="http://table.yml">table.yml table</a> will be
-assigned to the block parameters and run through the subsequent assertion.
-</p>
-<pre>
-    Table 'fixtures/table.yml' do |x, y|
-      x.upcase.assert == y
-    end
-</pre>
-</body>
-    </div>
-  </div>
-</body>
-</html>
-<script src="../assets/scripts/spec.js" type="text/javascript" language="javascript"></script>
-<script type="text/javascript" language="javascript">
-  /*****************************************************************
-   * $.toc()
-   * by rebecca murphey
-   * rmurphey gmail com
-   *
-   * This function is called on its own and takes as an argument
-   * a list of selectors with which it will build a table of
-   * contents.
-   *
-   * The first selector will make up the top level of the TOC;
-   * the second selector will make up the second level of the TOC;
-   * etc.
-   *
-   * This function returns a div containing nested unordered lists;
-   * each list item is linked to an anchor tag added before the item
-   * on the page.
-   *
-   * usage: $.toc('h1,h2,h3').prependTo('body');
-   ************************************************************************/
-  (function($) {
-    $.toc = function(tocList) {
-      $(tocList).addClass('jquery-toc');
-      var tocListArray = tocList.split(',');
-      $.each(tocListArray, function(i,v) { tocListArray[i] = $.trim(v); });
-      var $elements = $('.jquery-toc');
-      $('body').append('<div></div>');
-      var $toc = $('body div:last');
-      var lastLevel = 1;
-      $toc.append('<ul class="jquery-toc-1"></ul>');
-      $elements.each(function() {
-        var $e = $(this);
-        var text = $e.text();
-        var anchor = text.replace(/ /g,'-');
-        $e.before('<a name="' + anchor + '"></a>');
-        var level;
-        $.each(tocListArray, function(i,v) {
-          if (v.match(' ')) {
-            var vArray = v.split(' ');
-            var e = vArray[vArray.length - 1];
-          } else { e = v; }
-          if ($e.is(e)) { level = i+1; }
-        });
-        var className = 'jquery-toc-' + level;
-        var li = '<li><a href="#' + anchor + '">' + text + '</a></li>';
-        if (level == lastLevel) {
-          $('ul.' + className + ':last',$toc).append(li);
-        } else if (level > lastLevel) {
-          var parentLevel = level - 1;
-          var parentClassName = 'jquery-toc-' + parentLevel;
-          $('ul.' + parentClassName + ':last',$toc).
-            append('<ul class="' + className + '"></ul>');
-          $('ul.' + className + ':last',$toc).append(li);
-        } else if (level < lastLevel) {
-          $('ul.' + className + ':last',$toc).append(li);
-        }
-        lastLevel = level;
-      });
-      var $toc_ul = $('ul.jquery-toc-1',$toc);
-      $toc.remove();
-      return($toc_ul);
-   }
-  })(jQuery);
-</script>
-<script>
-  function toc_toggle() {
-    $('#toc_side').toggle();
-    $("pre").addClass("pass");
-    $("pre:contains('FAIL:')").addClass("fail");
-    $("pre:contains('ERROR:')").addClass("error");
-  };
-  $.toc('#content h1,h2,h3,h4').appendTo('.toc');
-  toc_toggle();
-</script>