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.
Code samples with magic comments
You will need to
$ gem install mountain_berry_fields-magic_comments
for this to work.
# MyLibName <% test 'an example', with: :magic_comments do %> MyLibName.new('some data').result # => "some cool result" <% end %>
$ mountain_berry_fields Readme.mountain_berry_fields.md and it will generate
# 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.
Code samples with RSpec
You will need to
$ gem install mountain_berry_fields-rspec
for this to work.
# 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 %>
$ mountain_berry_fields Readme.mountain_berry_fields.md to generate
# 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)>'
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.
Some examples may need to be executed within a context. Use a context block for that.
__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 %>
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.
Creating your own test strategy
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
#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.
About the name
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
Features to add for v2
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
- -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