specdown 0.2.1 → 0.3.0

data/CHANGELOG.markdown

@@ -1,5 +1,36 @@
 ## CHANGELOG
 
+## 0.3.0
+
+NOTICE: Non-backwards compatible release.
+
+specdown now supports github-flavored fenced codeblocks!
+
+If you want your codeblock executed in your tests, you must explicitly
+mark it as a `ruby` codeblock:
+
+    # Example Markdown
+    
+    Specdown will execute the following codeblock:
+    
+    ```ruby
+    I execute
+    ```
+    
+    Specdown will ignore the following codeblocks:
+    
+    ```javascript
+    console.log("hi");
+    ```
+
+        indented code block
+
+    ```
+    this code block is fenced, but not explicitly 
+    tagged as ruby. therefore, specdown will not execute
+    it.
+    ```
+
 ## 0.2.1
 
 Bug fix: -f command line option was broken completely. FACE RED :D

data/README.markdown

@@ -6,17 +6,38 @@ Write your README in markdown, and execute it with specdown.
 
 ## Why?
 
-Simply put, `specdown` takes README DRIVEN DEVELOPMENT one step further by making your markdown executable.
-
-If you don't know what README DRIVEN DEVELOPMENT IS, checkout Tom Preston Werner's blog post ["README Driven Development"](http://tom.preston-werner.com/2010/08/23/readme-driven-development.html)
-
-## CAVEAT
-
-This library is very new. It has only a few features, but it's growing rapidly. Follow this repo to stay up to date on the latest changes, or better yet, fork and implement some needed features (see the TODO list at the end of this README).
+When you write a README for a library, a class, a command, etc., you're
+forced to stop and consider your user:
+
+* how are they going to use it?
+* what's the API
+* how am I going to convince them to use my library?
+
+What if you write the README first, before writing your code? This is the
+premise of README Driven Development. See Tom Preston-Werner's [blog post](http://tom.preston-werner.com/2010/08/23/readme-driven-development.html)
+on the topic for a quick introduction to all of its benefits.
+
+### Duplication
+
+One pain point I've encountered with README Driven Development is
+duplication between my tests and my documentation. Quite often, I'll end up
+spending a good deal of time translating most of my README's into executable tests in Cucumber or
+RSpec. Not only does this lower my productivity, it also forces me to
+maintain information about my code in two places: the documentation, and
+the tests. 
+
+Wouldn't it be great if your documentation and your tests were one and
+the same? For me, this was the promise of Cucumber, a tool I still use
+and love. However, I find that the repetitive nature of Gherkin, along
+with the hidden nature of the step definitions, mitigates against the
+likelihood that my feature files will actually serve as the primary
+documentation for my project. Readers will tune out when asked to read a page full of
+repetitive "Given/When/Then" scenarios, or they'll be forced to look elsewhere for the
+information they need because the step definitions hide the API.
 
 ## Installation
 
-Right now, specdown only support's Ruby. Next, I'll write a javascript implementation. Then, I don't know what language. Regardless, the goal is that you could use specdown with any programming language you desire.
+Right now, specdown only supports Ruby. Next, I'll write a javascript implementation. Then, I don't know what language. Regardless, the goal is that you could use specdown with any programming language you desire.
 
 To install the `specdown` ruby gem, simply:
 
@@ -26,15 +47,15 @@ It comes with a `specdown` command. Try running it. Doesn't matter where.
 
 ## Usage
 
-Let's write a simple test in markdown, and execute it with specdown. Create a "specdown" directory, then save the following text into a file inside of it. I'll assume you're calling it "example.markdown":
+Let's write a simple test in ([github-flavored](http://github.github.com/github-flavored-markdown/)) markdown, and execute it with specdown. Create a "specdown" directory, then save the following text into a file inside of it. I'll assume you're calling it "example.markdown":
 
-```markdown
-# Our first test!
+    # Our first test!
 
-This is our very first test. It's going to blow your mind.
+    This is our very first test. It's going to blow your mind.
 
+    ```ruby
     raise "WTF?" unless 1 == 1
-```
+    ```
 
 Ok, if you've been following along, then `ls -R` should return the following directory structure:
 
@@ -54,6 +75,7 @@ Great. Now run the `specdown` command:
 
         1 markdown
         1 test
+        1 success
         0 failures
 ```
 
@@ -65,31 +87,37 @@ Booya!
 
 Let's update our README to help illustrate this:
 
-```markdown
-# Our first test!
-
-This is our very first test. It's going to blow your mind.
+    # Our first test!
 
+    This is our very first test. It's going to blow your mind.
+    
+    ```ruby
     raise "WTF?" unless 1 == 1
+    ```
 
-## A Subsection
+    ## A Subsection
 
-In this section, we're going to create a variable.
+    In this section, we're going to create a variable.
 
+    ```ruby
     name = "moonmaster9000"
+    ```
 
-### A sub subsection
+    ### A sub subsection
 
-In this subsection, we have access to anything created or within scope in parent sections:
+    In this subsection, we have access to anything created or within scope in parent sections:
 
+    ```ruby
     raise "name not in scope" if !defined? name
+    ```
 
-## Another Subsection
-
-In this subsection, we don't have access to the "name" variable. Think of your markdown as a tree.
+    ## Another Subsection
 
+    In this subsection, we don't have access to the "name" variable. Think of your markdown as a tree.
+    
+    ```ruby
     raise "name in scope" if defined? name
-```
+    ```
 
 Read through that. I'm giving you some important scoping hints in it. 
 
@@ -138,9 +166,46 @@ raise "WTF?" unless 1 == 1
 raise "name in scope" if defined? name
 ```
 
+## Non-executing code blocks
+
+It's likely that in the process of writing your documentation tests, you'll want
+to add some code into your markdown that you don't want executed.
+Perhaps it's code in a different language, or perhaps you're showing off
+some command line functionality.
+
+Specdown only executes fenced codeblocks specifically flagged as `ruby`.
+Thus, if you want to add some code to your markdown that shouldn't be
+executed, then just don't specifically flag it as Ruby:
+
+    # Non-Executing Code Blocks Example
+    
+    Here's an example of a non-executing code block:
+    
+        $ cd /
+    
+    Here's another example of a non-executing code block:
+        
+    ```javascript
+    console.log("I'm javascript, so I won't execute.");
+    ```
+
+    A third example:
+    
+    ```
+    I'm not flagged as anything, so I won't execute.
+    ```
+
+    ## Executing codeblocks
+    
+    The only way to make a code block execute is to specifically flag it as Ruby
+    
+    ```ruby
+    puts "I execute!"
+    ```
+
 ## Setting up your test environment
 
-Similar to the cucumber testing framework: If you put a ruby file somewhere inside your "specdown" directory, `specdown` will find it and load it.
+Similar to the cucumber testing framework: if you put a ruby file somewhere inside your "specdown" directory, `specdown` will find it and load it.
 
 ### Configuring the Expectation / Assertion framework
 
@@ -228,7 +293,7 @@ If you want to run just a single file or a set of files, or a directory of files
 
 ```sh
 $ specdown specdown/test.markdown
-$ specdown specdown/unit_tests
+$ specdown specdown/unit_tests specdown/simple.markdown specdown/integration_tests/
 ```
 
 ### Overriding the default root directory
@@ -247,7 +312,7 @@ By default, `specdown` will output colorized terminal output. If you'd rather th
 $ specdown -n
 ```
 
-You can also configure colorization in your env.rb by setting the
+You can also turn off colorization in your env.rb by setting the
 reporter to `Specdown::TerminalReporter`:
 
 ```ruby
@@ -279,11 +344,12 @@ You can also configure this in your env.rb by setting
 Specdown::Config.format = :condensed
 ```
 
-The default it `short`.
+The default is `:short`.
 
 ## TODO
 
 This library is still very new, but I am rapidly adding features to it. Here's what is on the immediate horizon:
 
+* allow flagged text in the markdown to execute code, like a cucumber step definition
 * offer the option of outputing the actual markdown while it executes, instead of "..F....FF......"
 * Better stack traces / reporting

data/VERSION

@@ -1 +1 @@
-0.2.1
+0.3.0

data/features/command.feature

@@ -18,27 +18,33 @@ Feature: `specdown` command
     
     Given I have a specdown directory containing a single markdown file:
       """
-        # Specdown Example
+      # Specdown Example
 
-        This is an example specdown file.
+      This is an example specdown file.
 
-        ## Child Node
+      ## Child Node
 
-        This section is a child node. It contains some ruby code: 
-            
-            "simple code".should_not be(nil)
+      This section is a child node. It contains some ruby code: 
+          
+      ```ruby
+      "simple code".should_not be(nil)
+      ```
 
-        ### First Leaf
+      ### First Leaf
 
-        This section has a failure simulation:
-            
-            raise "specdown error simulation!"
+      This section has a failure simulation:
+          
+      ```ruby
+      raise "specdown error simulation!"
+      ```
 
-        ## Last Leaf
+      ## Last Leaf
 
-        This section is a leaf node. It contains some ruby code:
-            
-            1.should satisfy(&:odd?)
+      This section is a leaf node. It contains some ruby code:
+
+      ```ruby
+      1.should satisfy(&:odd?)
+      ```
       """
 
     When I run `specdown` with no arguments
@@ -56,27 +62,33 @@ Feature: `specdown` command
   Scenario: `specdown` with no arguments, and a specdown directory containing a single ruby file and a single markdown file
     Given I have a specdown directory containing a markdown file:
       """
-        # Specdown Example
+      # Specdown Example
+
+      This is an example specdown file.
 
-        This is an example specdown file.
+      ## Child Node
 
-        ## Child Node
+      This section is a child node. It contains some ruby code: 
+          
+      ```ruby
+      "simple code".should_not be(nil)
+      ```
 
-        This section is a child node. It contains some ruby code: 
-            
-            "simple code".should_not be(nil)
+      ### First Leaf
 
-        ### First Leaf
+      This section has a failure simulation:
+          
+      ```ruby
+      raise "specdown error simulation!"
+      ```
 
-        This section has a failure simulation:
-            
-            raise "specdown error simulation!"
+      ## Last Leaf
 
-        ## Last Leaf
+      This section is a leaf node. It contains some ruby code:
 
-        This section is a leaf node. It contains some ruby code:
-            
-            1.should satisfy(&:odd?)
+      ```ruby
+      1.should satisfy(&:odd?)
+      ```
       """
     And a single ruby file:
       """

data/features/fixtures/multiple_codeblocks_per_section_example.markdown

@@ -0,0 +1,11 @@
+# Specdown Example
+
+This is an example specdown file.
+
+```ruby
+hi = 'hello'
+```
+
+```ruby
+puts hi
+```

data/features/fixtures/non_executing_example.markdown

@@ -0,0 +1,29 @@
+# Specdown Example
+
+This is an example specdown file.
+
+## Executing Code blocks
+
+This section contains an executing code block: 
+    
+```ruby
+"simple code".should_not be(nil)
+```
+
+It also contains a non-executing code block:
+
+    raise "I should not execute!"
+
+## More non executing code blocks
+
+This section has two non-executing code blocks:
+
+```javascript
+console.log("I won't execute!");
+```
+
+and...
+
+```
+$ cd /
+```

data/features/fixtures/parser_example.markdown

@@ -6,16 +6,22 @@ This is an example specdown file.
 
 This section is a child node. It contains some ruby code: 
     
-    "simple code".should_not be(nil)
+```ruby
+"simple code".should_not be(nil)
+```
 
 ### First Leaf
 
 This section has a failure simulation:
     
-    raise "specdown error simulation!"
+```ruby
+raise "specdown error simulation!"
+```
 
 ## Last Leaf
 
 This section is a leaf node. It contains some ruby code:
-    
-    1.should satisfy(&:odd?)
+
+```ruby
+1.should satisfy(&:odd?)
+```

data/features/parser.feature

@@ -14,20 +14,26 @@ Feature: Specdown Parser
 
         This section is a child node. It contains some ruby code: 
             
-            "simple code".should_not be(nil)
+        ```ruby
+        "simple code".should_not be(nil)
+        ```
 
         \### First Leaf
 
         This section has a failure simulation:
             
-            raise "specdown error simulation!"
+        ```ruby
+        raise "specdown error simulation!"
+        ```
 
         \## Last Leaf
 
         This section is a leaf node. It contains some ruby code:
-            
-            1.should satisfy(&:odd?)
-       README
+        
+        ```ruby
+        1.should satisfy(&:odd?)
+        ```
+      README
 
   As you can see, this forms a tree, with "# Specdown Example" at the root of the tree, and "## Leaf 1" and "## Leaf 2" as the children / leafs. 
 
@@ -55,27 +61,33 @@ Feature: Specdown Parser
 
     Given the following specdown example file:
       """
-        # Specdown Example
+      # Specdown Example
 
-        This is an example specdown file.
+      This is an example specdown file.
 
-        ## Child Node
+      ## Child Node
 
-        This section is a child node. It contains some ruby code: 
-            
-            "simple code".should_not be(nil)
+      This section is a child node. It contains some ruby code: 
+          
+      ```ruby
+      "simple code".should_not be(nil)
+      ```
 
-        ### First Leaf
+      ### First Leaf
 
-        This section has a failure simulation:
-            
-            raise "specdown error simulation!"
+      This section has a failure simulation:
+          
+      ```ruby
+      raise "specdown error simulation!"
+      ```
 
-        ## Last Leaf
+      ## Last Leaf
 
-        This section is a leaf node. It contains some ruby code:
-            
-            1.should satisfy(&:odd?)
+      This section is a leaf node. It contains some ruby code:
+      
+      ```ruby
+      1.should satisfy(&:odd?)
+      ```
       """
 
     When I parse it into a tree:
@@ -106,3 +118,83 @@ Feature: Specdown Parser
         last_leaf.name.should   == "Last Leaf"
         last_leaf.code.should   == "1.should satisfy(&:odd?)" 
       """
+
+
+  Scenario: Parsing a specdown file
+
+    Given the following specdown example file containing non-executing codeblocks:
+      """
+      # Specdown Example
+
+      This is an example specdown file.
+
+      ## Executing Code blocks
+
+      This section contains an executing code block: 
+          
+      ```ruby
+      "simple code".should_not be(nil)
+      ```
+
+      It also contains a non-executing code block:
+
+          raise "I should not execute!"
+
+      ## More non executing code blocks
+
+      This section has two non-executing code blocks:
+
+      ```javascript
+      console.log("I won't execute!");
+      ```
+
+      and...
+
+      ```
+      $ cd /
+      ```
+      """
+
+    When I parse it into a tree:
+      """
+        @tree = Specdown::Parser.parse @readme
+      """
+
+    Then the first leaf should contain only the explicit ruby code:
+      """
+        @tree.root.children.first.code.should == '"simple code".should_not be(nil)'
+      """
+
+    And the second leaf should not contain any executable code:
+      """
+        @tree.root.children.last.code.should be_empty
+      """
+
+
+  @focus
+  Scenario: Multiple code blocks in a section should join together with newlines
+
+    Given the following specdown example file containing multiple executable codeblocks in a single section:
+      """
+      # Specdown Example
+
+      This is an example specdown file.
+
+      ```ruby
+      hi = 'hello'
+      ```
+
+      ```ruby
+      puts hi
+      ```
+      """
+
+    When I parse it into a tree:
+      """
+        @tree = Specdown::Parser.parse @readme
+      """
+
+    Then the code blocks should be joined together with newlines:
+      """
+        @tree.root.code.should == "hi = 'hello'\nputs hi"
+      """

data/features/report_summary.feature

@@ -22,19 +22,25 @@ Feature: Specdown::ReportSummary
 
       This section is a child node. It contains some ruby code: 
           
-          "simple code".should_not == nil
+      ```ruby
+      "simple code".should_not be(nil)
+      ```
 
       ### First Leaf
 
       This section has a failure simulation:
           
-          raise "specdown error simulation!"
+      ```ruby
+      raise "specdown error simulation!"
+      ```
 
       ## Last Leaf
 
       This section is a leaf node. It contains some ruby code:
-          
-          1.should == 1
+
+      ```ruby
+      1.should satisfy(&:odd?)
+      ```
       """
     
     And the following runner:

data/features/runner.feature

@@ -12,19 +12,25 @@ Feature: Runner
 
       This section is a child node. It contains some ruby code: 
           
-          "simple code".should_not == nil
+      ```ruby
+      "simple code".should_not be(nil)
+      ```
 
       \### First Leaf
 
       This section has a failure simulation:
           
-          raise "specdown error simulation!"
+      ```ruby
+      raise "specdown error simulation!"
+      ```
 
       \## Last Leaf
 
       This section is a leaf node. It contains some ruby code:
-          
-          1.should == 1
+
+      ```ruby
+      1.should satisfy(&:odd?)
+      ```
   
   We can generate a `Specdown::Runner` instance and run the tests in our markdown by simply passing the filename on instantiation:
 
@@ -42,7 +48,7 @@ Feature: Runner
 
   Scenario: Running tests
 
-    Given the following specdown example file located at 'features/fixtures/parser_example.markdown':
+    Given the following specdown example file:
       """
       # Specdown Example
 
@@ -52,19 +58,25 @@ Feature: Runner
 
       This section is a child node. It contains some ruby code: 
           
-          "simple code".should_not == nil
+      ```ruby
+      "simple code".should_not be(nil)
+      ```
 
       ### First Leaf
 
       This section has a failure simulation:
           
-          raise "specdown error simulation!"
+      ```ruby
+      raise "specdown error simulation!"
+      ```
 
       ## Last Leaf
 
       This section is a leaf node. It contains some ruby code:
-          
-          1.should == 1
+
+      ```ruby
+      1.should satisfy(&:odd?)
+      ```
       """
 
     When I generate a `Specdown::Runner` instance from it:

data/features/specdown_examples/after_hooks/specdown/parser_example.markdown

@@ -6,16 +6,23 @@ This is an example specdown file.
 
 This section is a child node. It contains some ruby code: 
     
-    "simple code".should_not be(nil)
+```ruby
+"simple code".should_not be(nil)
+```
 
 ## First Leaf
 
 This section has a failure simulation:
     
-    raise "specdown error simulation!"
+```ruby
+raise "specdown error simulation!"
+```
 
 ## Last Leaf
 
 This section is a leaf node. It contains some ruby code:
-    
-    1.should satisfy(&:odd?)
+
+```ruby
+1.should satisfy(&:odd?)
+```
+

data/features/specdown_examples/around_hooks/specdown/parser_example.markdown

@@ -6,4 +6,6 @@ This is an example specdown file.
 
 This section is a child node. It contains some ruby code: 
     
-    "simple code".should_not be(nil)
+```ruby
+"simple code".should_not be(nil)
+```

data/features/specdown_examples/before_hooks/specdown/parser_example.markdown

@@ -6,17 +6,22 @@ This is an example specdown file.
 
 This section is a child node. It contains some ruby code: 
     
-    "simple code".should_not be(nil)
+```ruby
+"simple code".should_not be(nil)
+```
 
 ### First Leaf
 
 This section has a failure simulation:
     
-    raise "specdown error simulation!"
+```ruby
+raise "specdown error simulation!"
+```
 
 ## Last Leaf
 
 This section is a leaf node. It contains some ruby code:
-    
-    1.should satisfy(&:odd?)
 
+```ruby
+1.should satisfy(&:odd?)
+```

data/features/specdown_examples/no_ruby/specdown/parser_example.markdown

@@ -6,17 +6,22 @@ This is an example specdown file.
 
 This section is a child node. It contains some ruby code: 
     
-    "simple code".should_not be(nil)
+```ruby
+"simple code".should_not be(nil)
+```
 
 ### First Leaf
 
 This section has a failure simulation:
     
-    raise "specdown error simulation!"
+```ruby
+raise "specdown error simulation!"
+```
 
 ## Last Leaf
 
 This section is a leaf node. It contains some ruby code:
-    
-    1.should satisfy(&:odd?)
 
+```ruby
+1.should satisfy(&:odd?)
+```

data/features/specdown_examples/scoped_hooks/specdown/parser_example.markdown

@@ -6,16 +6,23 @@ This is an example specdown file.
 
 This section is a child node. It contains some ruby code: 
     
-    "simple code".should_not be(nil)
+```ruby
+"simple code".should_not be(nil)
+```
 
-## First Leaf
+### First Leaf
 
 This section has a failure simulation:
     
-    raise "specdown error simulation!"
+```ruby
+raise "specdown error simulation!"
+```
 
 ## Last Leaf
 
 This section is a leaf node. It contains some ruby code:
-    
-    1.should satisfy(&:odd?)
+
+```ruby
+1.should satisfy(&:odd?)
+```
+

data/features/specdown_examples/scoped_hooks/specdown/spec1.fun.markdown

@@ -6,4 +6,6 @@ This is an example specdown file.
 
 This section is a child node. It contains some ruby code: 
     
-    "simple code".should_not be(nil)
+```ruby
+"simple code".should_not be(nil)
+```

data/features/specdown_examples/scoped_hooks/specdown/spec2.fun.markdown

@@ -6,5 +6,6 @@ This is an example specdown file.
 
 This section is a child node. It contains some ruby code: 
     
-    "simple code".should_not be(nil)
-
+```ruby
+"simple code".should_not be(nil)
+```

data/features/specdown_examples/scoped_hooks/specdown/spec3.markdown

@@ -6,5 +6,6 @@ This is an example specdown file.
 
 This section is a child node. It contains some ruby code: 
     
-    "simple code".should_not be(nil)
-
+```ruby
+"simple code".should_not be(nil)
+```

data/features/specdown_examples/with_ruby/specdown/parser_example.markdown

@@ -6,17 +6,22 @@ This is an example specdown file.
 
 This section is a child node. It contains some ruby code: 
     
-    "simple code".should_not be(nil)
+```ruby
+"simple code".should_not be(nil)
+```
 
 ### First Leaf
 
 This section has a failure simulation:
     
-    raise "specdown error simulation!"
+```ruby
+raise "specdown error simulation!"
+```
 
 ## Last Leaf
 
 This section is a leaf node. It contains some ruby code:
-    
-    1.should satisfy(&:odd?)
 
+```ruby
+1.should satisfy(&:odd?)
+```

data/features/step_definitions/parser.rb

@@ -1,7 +1,15 @@
-Given /^the following specdown example file.*:$/ do |string|
+Given /^the following specdown example file containing non\-executing codeblocks:$/ do |string|
+  @readme = File.read "features/fixtures/non_executing_example.markdown"
+end
+
+Given /^the following specdown example file:$/ do |string|
   @readme = File.read "features/fixtures/parser_example.markdown"
 end
 
+Given /^the following specdown example file containing multiple executable codeblocks in a single section:$/ do |string|
+  @readme = File.read "features/fixtures/multiple_codeblocks_per_section_example.markdown"
+end
+
 When /^I parse it into a tree:$/ do |string|
   eval string
 end
@@ -13,3 +21,15 @@ end
 Then /^the root should have two children:$/ do |string|
   eval string
 end
+
+Then /^the first leaf should contain only the explicit ruby code:$/ do |string|
+  eval string
+end
+
+Then /^the second leaf should not contain any executable code:$/ do |string|
+  eval string
+end
+
+Then /^the code blocks should be joined together with newlines:$/ do |string|
+  eval string
+end

data/lib/specdown/parser.rb

@@ -3,7 +3,7 @@ module Specdown
     extend self
 
     def parse(readme)
-      kramdown = Kramdown::Document.new readme, :input => :markdown
+      kramdown = Kramdown::Document.new readme, :input => "GithubMarkdown"
       build_tree kramdown.root.children
     end
 
@@ -43,7 +43,7 @@ module Specdown
 
       while !parsed_elements.empty? && parsed_elements.first.type != :header
         element        = parsed_elements.shift
-        node.code     += element.value if element.type == :codeblock
+        node.code     += "\n" + element.value.to_s.strip if element.type == :codeblock && element.options["language"] == "ruby"
         node.contents += element.value.to_s + element.children.map(&:value).join
       end
       node

metadata

@@ -1,13 +1,13 @@
 --- !ruby/object:Gem::Specification 
 name: specdown
 version: !ruby/object:Gem::Version 
-  hash: 21
+  hash: 19
   prerelease: 
   segments: 
   - 0
-  - 2
-  - 1
-  version: 0.2.1
+  - 3
+  - 0
+  version: 0.3.0
 platform: ruby
 authors: 
 - Matt Parker
@@ -15,22 +15,22 @@ autorequire:
 bindir: bin
 cert_chain: []
 
-date: 2012-01-13 00:00:00 Z
+date: 2012-01-16 00:00:00 Z
 dependencies: 
 - !ruby/object:Gem::Dependency 
-  name: kramdown
+  name: gitdown
   prerelease: false
   requirement: &id001 !ruby/object:Gem::Requirement 
     none: false
     requirements: 
     - - ~>
       - !ruby/object:Gem::Version 
-        hash: 35
+        hash: 27
         segments: 
         - 0
-        - 13
-        - 4
-        version: 0.13.4
+        - 0
+        - 2
+        version: 0.0.2
   type: :runtime
   version_requirements: *id001
 - !ruby/object:Gem::Dependency 
@@ -127,6 +127,8 @@ files:
 - features/config.feature
 - features/event_server.feature
 - features/exception_facade.feature
+- features/fixtures/multiple_codeblocks_per_section_example.markdown
+- features/fixtures/non_executing_example.markdown
 - features/fixtures/parser_example.markdown
 - features/hooks.feature
 - features/parser.feature
@@ -208,6 +210,8 @@ test_files:
 - features/config.feature
 - features/event_server.feature
 - features/exception_facade.feature
+- features/fixtures/multiple_codeblocks_per_section_example.markdown
+- features/fixtures/non_executing_example.markdown
 - features/fixtures/parser_example.markdown
 - features/hooks.feature
 - features/parser.feature