MountainBerryFields

Tests code samples embedded in files, such as readmes, it generates the real file if the tests are successful.

When you have a file with embedded code samples, rename it to include a .mountain_berry_fields suffix. Then wrap test statements around the code samples. I've written two testing strategies: rspec and magic_comments. You can create your own without much effort.

You will need to $ gem install mountain_berry_fields-magic_comments for this to work.

The file Readme.mountain_berry_fields.md

# MyLibName

    <% test 'an example', with: :magic_comments do %>
    MyLibName.new('some data').result # => "some cool result"
    <% end %>

Run $ mountain_berry_fields Readme.mountain_berry_fields.md and it will generate Readme.md

# MyLibName

    MyLibName.new('some data').result # => "some cool result"

If at some point, you change your lib to not do that cool thing, then it will not generate the file. Instead it will give you an error message:

FAILURE: an example
Expected: MyLibName.new('some data').result # => "some cool result"
Actual:   MyLibName.new('some data').result # => "some unexpected result"

Now you can be confident that your code is still legit.

Realworld example.

You will need to $ gem install mountain_berry_fields-rspec for this to work.

The file Readme.mountain_berry_fields.md

# MyLibName

    <% test 'an example', with: :rspec do %>
    RSpec.describe MyLibName do
      it 'does what I made it do' do
        result = described_class.new('some data').result
        expect(result).to eq 'some cool result'
      end
    end
    <% end %>

Run $ mountain_berry_fields Readme.mountain_berry_fields.md to generate Readme.md

# MyLibName

    RSpec.describe MyLibName do
      it 'does what I made it do' do
        result = described_class.new('some data').result
        expect(result).to eq 'some cool result'
      end
    end

And an rspec error:

FAILURE: an example
MyLibName does what I made it do:
  
expected: "some cool result"
     got: "some unexpected result"

(compared using ==)

backtrace:
  /spec.rb:9:in `block (2 levels) in <top (required)>'

Realworld example.

You may need to do something to setup the environment for the tests (e.g. load the lib your examples are using) Do that with a setup block:

<% setup do %>
$LOAD_PATH.unshift File.expand_path '../lib', __FILE__
require 'my_lib_name'
<% end %>

This will not show up anywhere in the generated file. It will be prepended before each code sample when running tests.

Realworld example.

Some examples may need to be executed within a context. Use a context block for that. Use the __CODE__ macro to indicate where the code should go relative to this context.

<% context 'a user named Carlita' do %>
user = Struct.new(:name).new 'Carlita'
__CODE__
<% end %>

<% test 'users have a name', context: 'a user named Carlita', with: :magic_comments do %>
user.name # => "Carlita"
<% end %>

Context blocks can, themselves, be rendered into a context <% context 'current', context: "my context's context" do %>

Realworld example.

If you want to add this as part of your build, there is a rake task:

require 'mountain_berry_fields/rake_task'
MountainBerryFields::RakeTask.new(:mbf, 'Readme.mountain_berry_fields.md')

which will allow you to say $ rake mbf. You could then add it to your default task with task default: :mbf, or have whatever task runs your tests just execute it at the end.

Realworld example.

I've written the magic_comments and rspec strategies. You can write your own that do whatever interesting thing you've thought of.

If you want it to be a gem, then the strategy needs to be in the file mountain_berry_fields/test/your_strategy.rb. Mountain Berry Fields will automatically load files at these paths. If your strategy is not a gem, then it is up to you to ensure the code defining the strategy is loaded.

Any strategy can be made accessible to the .mountain_berry_fields file like this: MountainBerryFields::Test::Strategy.register :your_strategy, YourStrategy And then accessed by <% test 'testname', with: :your_strategy do %>

Strategies will be initialized with the code to test, and are expected to implement #pass? which returns a boolean of whether the code passes according to that strategy, and #failure_message which will used to describe why the spec failed to users.

Realworld gem example. Realworld non-gem example, and the code that loads it.

I am often asked why I picked this name. I make things like this for me, because I have decided that they have value. I felt the need to remind myself of that so I chose a name that no one would realisitcally choose, to remind myself of the fact that no one could tell me I couldn't choose it.

The phrase "Mountain berry fields" is a lyric in a song that makes me happy.

If it bothers you: $ alias mbf=mountain_berry_fields

Note that my use cases are to be able to test Deject and Surrogate, which this currently does quite nicely. As a result, I have no imminent need for any of these features, and so they are not a priority for me. If you have a need for them (or for other features), let me know and that will cause it to be a much higher priority for me. Alternatively, pull requests that add them, fix bugs, or generally make it better, are more than welcome.

• contexts should be lazy (can define context after a block that uses it)
• should be able to pass options to the initializer
• enable the test strategy to decide what should be returned
• support for multiple input files to the binary
• FLAGS:
• • -o set up input files so they don't need a .mountain_berry_fields in their name (output filename is provided, so input filename needs no naming conventions)
• • -s list all known test strategies
• • -v version
• • -c check syntax (no output, thus also no input filename restrictions)
• • -e flag for outputting erb (e.g. when it gives weird ass _buf error)
• • -h to display this menu
• • ?? to display the code that was passed to the test, along with the failure