I created a gem called rspec_n that installs an executable that will do this. It will re-run the test suite N times by default. You can make it stop as soon as it hits a failing iteration via the -s cli option. It will display other stats about the iterations as well.

The shared context worked though thanks! RSpec.shared_context "perform_enqueued_jobs" do around(:each) { |example| perform_enqueued_jobs { example.run } } end RSpec.configure do |config| config.include_context "perform_enqueued_jobs" end

group.run(double.as_null_object)

config.define_derived_metadata(let_it_be_frost: true) do |metadata| metadata[:let_it_be_modifiers] ||= {freeze: true} end

Just FYI, there is a nice way to "expect a change" in RSpec. You don't have to use it, what you have is fine, just thought I'd share. expect { widget.paper_trail.update_columns(name: "Bugle") }.to(change { widget.versions.length }).from(1).to(2)

Rspec hangs after it finishes running through my tests

We use the RSpec::Parameterized gem

using RSpec::Parameterized::TableSyntax where(:a, :b, :answer) do 1 | 2 | 3 5 | 8 | 13 0 | 0 | 0 end

Move it to Jest. This potentially requires extending our jsdom mocked browser environment. Move it to RSpec. This will probably require us changing our perspective to a use-case oriented one. We just want to make sure we have the same value coverage.

Also if I replace the shared_context with shared_examples and accordingly include it in test case. Passes

If you look at the source code you'll see that they're exactly the same thing.

Very trivial and cosmetic, but include_context doesn't output "behaves like" in --format documentation.

It's simple really ... put tests into a shared example that you want multiple things to conform to. Put code into a shared context that you need to include in multiple tests.

shared_contexts is any setup code that you can use to prepare a test case . This allows you to include test helper methods or prepare for the tests to run.

alias shared_context shared_examples

describe '.validate(context, filters, inputs)' do let(:inputs) { {} } let(:filter) { ActiveInteraction::Filter.new(:name, {}) } let(:interaction) do

We also use a home-made RspecFlaky::Listener listener which records flaky examples in a JSON report file on master (retrieve-tests-metadata and update-tests-metadata jobs).

a technique that enable a test suite to perform as well as using fixtures (or better if you're running just a few tests from the suite) and read as good as you are used to when using factories

No need for DatabaseCleaner (rolling back transactions are usually faster than truncate).

But where is the helper method defined? What’s its visibility? Can I put it in a module? Can I use inheritance? Who can call it? Can I call super from the extracted method? If so, where does super go?

minitest doesn't reinvent anything that ruby already provides, like: classes, modules, inheritance, methods. This means you only have to learn ruby to use minitest and all of your regular OO practices like extract-method refactorings still apply.

heavily inspired in RSpec Expectations