base on RSpec runner and formatters # rspec-core [](https://github.com/rspec/rspec-core/actions) [](https://codeclimate.com/github/rspec/rspec-core) rspec-core provides the structure for writing executable examples of how your code should behave, and an `rspec` command with tools to constrain which examples get run and tailor the output. **This is the old rspec core repository, please see the monorepo rspec/rspec for new issues and releases.** ## Install gem install rspec # for rspec-core, rspec-expectations, rspec-mocks gem install rspec-core # for rspec-core only rspec --help Want to run against the `main` branch? You'll need to include the dependent RSpec repos as well. Add the following to your `Gemfile`: ```ruby %w[rspec rspec-core rspec-expectations rspec-mocks rspec-support].each do |lib| gem lib, :git => "https://github.com/rspec/#{lib}.git", :branch => 'main' end ``` ## Basic Structure RSpec uses the words "describe" and "it" so we can express concepts like a conversation: "Describe an order." "It sums the prices of its line items." ```ruby RSpec.describe Order do it "sums the prices of its line items" do order = Order.new order.add_entry(LineItem.new(:item => Item.new( :price => Money.new(1.11, :USD) ))) order.add_entry(LineItem.new(:item => Item.new( :price => Money.new(2.22, :USD), :quantity => 2 ))) expect(order.total).to eq(Money.new(5.55, :USD)) end end ``` The `describe` method creates an [ExampleGroup](http://rubydoc.info/gems/rspec-core/RSpec/Core/ExampleGroup). Within the block passed to `describe` you can declare examples using the `it` method. Under the hood, an example group is a class in which the block passed to `describe` is evaluated. The blocks passed to `it` are evaluated in the context of an _instance_ of that class. ## Nested Groups You can also declare nested groups using the `describe` or `context` methods: ```ruby RSpec.describe Order do context "with no items" do it "behaves one way" do # ... end end context "with one item" do it "behaves another way" do # ... end end end ``` Nested groups are subclasses of the outer example group class, providing the inheritance semantics you'd want for free. ## Aliases You can declare example groups using either `describe` or `context`. For a top level example group, `describe` and `context` are available off of `RSpec`. For backwards compatibility, they are also available off of the `main` object and `Module` unless you disable monkey patching. You can declare examples within a group using any of `it`, `specify`, or `example`. ## Shared Examples and Contexts Declare a shared example group using `shared_examples`, and then include it in any group using `include_examples`. ```ruby RSpec.shared_examples "collections" do |collection_class| it "is empty when first created" do expect(collection_class.new).to be_empty end end RSpec.describe Array do include_examples "collections", Array end RSpec.describe Hash do include_examples "collections", Hash end ``` Nearly anything that can be declared within an example group can be declared within a shared example group. This includes `before`, `after`, and `around` hooks, `let` declarations, and nested groups/contexts. You can also use the names `shared_context` and `include_context`. These are pretty much the same as `shared_examples` and `include_examples`, providing more accurate naming when you share hooks, `let` declarations, helper methods, etc, but no examples. If you want to reuse shared examples or contexts across your RSpec suite you can define them in a stand alone _*.rb_ files (_spec/support/shared_examples/definition.rb_ for example). But you will have to manually `require` them (there is no autoloading of _spec/support/_ directory unless you set it up yourself). ## Metadata rspec-core stores a metadata hash with every example and group, which contains their descriptions, the locations at which they were declared, etc, etc. This hash powers many of rspec-core's features, including output formatters (which access descriptions and locations), and filtering before and after hooks. Although you probably won't ever need this unless you are writing an extension, you can access it from an example like this: ```ruby it "does something" do |example| expect(example.metadata[:description]).to eq("does something") end ``` ### `described_class` When a class is passed to `describe`, you can access it from an example using the `described_class` method, which is a wrapper for `example.metadata[:described_class]`. ```ruby RSpec.describe Widget do example do expect(described_class).to equal(Widget) end end ``` This is useful in extensions or shared example groups in which the specific class is unknown. Taking the collections shared example group from above, we can clean it up a bit using `described_class`: ```ruby RSpec.shared_examples "collections" do it "is empty when first created" do expect(described_class.new).to be_empty end end RSpec.describe Array do include_examples "collections" end RSpec.describe Hash do include_examples "collections" end ``` ## A Word on Scope RSpec has two scopes: * **Example Group**: Example groups are defined by a `describe` or `context` block, which is eagerly evaluated when the spec file is loaded. The block is evaluated in the context of a subclass of `RSpec::Core::ExampleGroup`, or a subclass of the parent example group when you're nesting them. * **Example**: Examples -- typically defined by an `it` block -- and any other blocks with per-example semantics -- such as a `before(:example)` hook -- are evaluated in the context of an _instance_ of the example group class to which the example belongs. Examples are _not_ executed when the spec file is loaded; instead, RSpec waits to run any examples until all spec files have been loaded, at which point it can apply filtering, randomization, etc. To make this more concrete, consider this code snippet: ``` ruby RSpec.describe "Using an array as a stack" do def build_stack [] end before(:example) do @stack = build_stack end it 'is initially empty' do expect(@stack).to be_empty end context "after an item has been pushed" do before(:example) do @stack.push :item end it 'allows the pushed item to be popped' do expect(@stack.pop).to eq(:item) end end end ``` Under the covers, this is (roughly) equivalent to: ``` ruby class UsingAnArrayAsAStack < RSpec::Core::ExampleGroup def build_stack [] end def before_example_1 @stack = build_stack end def it_is_initially_empty expect(@stack).to be_empty end class AfterAnItemHasBeenPushed < self def before_example_2 @stack.push :item end def it_allows_the_pushed_item_to_be_popped expect(@stack.pop).to eq(:item) end end end ``` To run these examples, RSpec would (roughly) do the following: ``` ruby example_1 = UsingAnArrayAsAStack.new example_1.before_example_1 example_1.it_is_initially_empty example_2 = UsingAnArrayAsAStack::AfterAnItemHasBeenPushed.new example_2.before_example_1 example_2.before_example_2 example_2.it_allows_the_pushed_item_to_be_popped ``` ## The `rspec` Command When you install the rspec-core gem, it installs the `rspec` executable, which you'll use to run rspec. The `rspec` command comes with many useful options. Run `rspec --help` to see the complete list. ## Store Command Line Options `.rspec` You can store command line options in a `.rspec` file in the project's root directory, and the `rspec` command will read them as though you typed them on the command line. ## Get Started Start with a simple example of behavior you expect from your system. Do this before you write any implementation code: ```ruby # in spec/calculator_spec.rb RSpec.describe Calculator do describe '#add' do it 'returns the sum of its arguments' do expect(Calculator.new.add(1, 2)).to eq(3) end end end ``` Run this with the rspec command, and watch it fail: ``` $ rspec spec/calculator_spec.rb ./spec/calculator_spec.rb:1: uninitialized constant Calculator ``` Address the failure by defining a skeleton of the `Calculator` class: ```ruby # in lib/calculator.rb class Calculator def add(a, b) end end ``` Be sure to require the implementation file in the spec: ```ruby # in spec/calculator_spec.rb # - RSpec adds ./lib to the $LOAD_PATH require "calculator" ``` Now run the spec again, and watch the expectation fail: ``` $ rspec spec/calculator_spec.rb F Failures: 1) Calculator#add returns the sum of its arguments Failure/Error: expect(Calculator.new.add(1, 2)).to eq(3) expected: 3 got: nil (compared using ==) # ./spec/calculator_spec.rb:6:in `block (3 levels) in <top (required)>' Finished in 0.00131 seconds (files took 0.10968 seconds to load) 1 example, 1 failure Failed examples: rspec ./spec/calculator_spec.rb:5 # Calculator#add returns the sum of its arguments ``` Implement the simplest solution, by changing the definition of `Calculator#add` to: ```ruby def add(a, b) a + b end ``` Now run the spec again, and watch it pass: ``` $ rspec spec/calculator_spec.rb . Finished in 0.000315 seconds 1 example, 0 failures ``` Use the `documentation` formatter to see the resulting spec: ``` $ rspec spec/calculator_spec.rb --format doc Calculator #add returns the sum of its arguments Finished in 0.000379 seconds 1 example, 0 failures ``` ## Contributing Once you've set up the environment, you'll need to cd into the working directory of whichever repo you want to work in. From there you can run the specs and cucumber features, and make patches. NOTE: You do not need to use rspec-dev to work on a specific RSpec repo. You can treat each RSpec repo as an independent project. * [Build details](BUILD_DETAIL.md) * [Code of Conduct](CODE_OF_CONDUCT.md) * [Detailed contributing guide](CONTRIBUTING.md) * [Development setup guide](DEVELOPMENT.md) ## Also see * [https://github.com/rspec/rspec-metagem](https://github.com/rspec/rspec-metagem) * [https://github.com/rspec/rspec-expectations](https://github.com/rspec/rspec-expectations) * [https://github.com/rspec/rspec-mocks](https://github.com/rspec/rspec-mocks) * [https://github.com/rspec/rspec-rails](https://github.com/rspec/rspec-rails) ", Assign "at most 3 tags" to the expected json: {"id":"315","tags":[]} "only from the tags list I provide: [{"id":77,"name":"3d"},{"id":89,"name":"agent"},{"id":17,"name":"ai"},{"id":54,"name":"algorithm"},{"id":24,"name":"api"},{"id":44,"name":"authentication"},{"id":3,"name":"aws"},{"id":27,"name":"backend"},{"id":60,"name":"benchmark"},{"id":72,"name":"best-practices"},{"id":39,"name":"bitcoin"},{"id":37,"name":"blockchain"},{"id":1,"name":"blog"},{"id":45,"name":"bundler"},{"id":58,"name":"cache"},{"id":21,"name":"chat"},{"id":49,"name":"cicd"},{"id":4,"name":"cli"},{"id":64,"name":"cloud-native"},{"id":48,"name":"cms"},{"id":61,"name":"compiler"},{"id":68,"name":"containerization"},{"id":92,"name":"crm"},{"id":34,"name":"data"},{"id":47,"name":"database"},{"id":8,"name":"declarative-gui "},{"id":9,"name":"deploy-tool"},{"id":53,"name":"desktop-app"},{"id":6,"name":"dev-exp-lib"},{"id":59,"name":"dev-tool"},{"id":13,"name":"ecommerce"},{"id":26,"name":"editor"},{"id":66,"name":"emulator"},{"id":62,"name":"filesystem"},{"id":80,"name":"finance"},{"id":15,"name":"firmware"},{"id":73,"name":"for-fun"},{"id":2,"name":"framework"},{"id":11,"name":"frontend"},{"id":22,"name":"game"},{"id":81,"name":"game-engine "},{"id":23,"name":"graphql"},{"id":84,"name":"gui"},{"id":91,"name":"http"},{"id":5,"name":"http-client"},{"id":51,"name":"iac"},{"id":30,"name":"ide"},{"id":78,"name":"iot"},{"id":40,"name":"json"},{"id":83,"name":"julian"},{"id":38,"name":"k8s"},{"id":31,"name":"language"},{"id":10,"name":"learning-resource"},{"id":33,"name":"lib"},{"id":41,"name":"linter"},{"id":28,"name":"lms"},{"id":16,"name":"logging"},{"id":76,"name":"low-code"},{"id":90,"name":"message-queue"},{"id":42,"name":"mobile-app"},{"id":18,"name":"monitoring"},{"id":36,"name":"networking"},{"id":7,"name":"node-version"},{"id":55,"name":"nosql"},{"id":57,"name":"observability"},{"id":46,"name":"orm"},{"id":52,"name":"os"},{"id":14,"name":"parser"},{"id":74,"name":"react"},{"id":82,"name":"real-time"},{"id":56,"name":"robot"},{"id":65,"name":"runtime"},{"id":32,"name":"sdk"},{"id":71,"name":"search"},{"id":63,"name":"secrets"},{"id":25,"name":"security"},{"id":85,"name":"server"},{"id":86,"name":"serverless"},{"id":70,"name":"storage"},{"id":75,"name":"system-design"},{"id":79,"name":"terminal"},{"id":29,"name":"testing"},{"id":12,"name":"ui"},{"id":50,"name":"ux"},{"id":88,"name":"video"},{"id":20,"name":"web-app"},{"id":35,"name":"web-server"},{"id":43,"name":"webassembly"},{"id":69,"name":"workflow"},{"id":87,"name":"yaml"}]" returns me the "expected json"