Project

respec

0.03
No release in over 3 years
Low commit activity in last 3 years
Rerun failing RSpec examples easily.
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
 Dependencies

Runtime

>= 2.11
 Project Readme

Respec Build Status Gem Version

Provides a command, respec, which wraps rspec, and records your failing examples for easy rerunning.

How?

Run your specs:

respec

3 fail. Rerun just the 3 failures like this:

respec f

Need to debug failure #1? Pop a debugger (or pry) in your code, and rerun it like this:

respec 1

This will just rerun failure 1. Once it's passing, rerun the 3 failing examples again:

respec f

1 is now fixed, but 2 and 3 are still failing - respec f will now only run failures 2 and 3 again.

How it works

All that's happening is the list of failed examples is being recorded in a file (.respec_failures). The f argument means "run these recorded failures only." A numeric argument like 1 means "just run that failure."

The list of failed examples is always updated except when selecting which failures to rerun with a number (more than one number can also be given, incidentally).

Other tricks

You can pass respec file or directory names, just like rspec. However, you can also just specify example names on the command line:

respec 'My example name'

If the argument doesn't name an existing file, it's assumed to be an example name.

It'll even bundle exec for you automatically, or use a binstub if present.

If you use git, run all specs modified since the last commit with:

respec d

(d for "git diff", which this uses.)

There are a few other shortcuts. respec --help to see them all.

If you're using this on CI to rerun your failures, you may want to control where the failure file is written. You can do this in one of 2 ways:

Either pass a FAILURES=... argument:

respec FAILURES=/path/to/file ...

Or use the RESPEC_FAILURES environment variable.

RESPEC_FAILURES=/path/to/file respec ...

Contributing

  • Bug reports
  • Source
  • Patches: Fork on Github, send pull request.
    • Include tests where practical.
    • Leave the version alone, or bump it in a separate commit.

Copyright

Copyright (c) George Ogata. See LICENSE for details.