Run all tests after success

I seem to remember when I was running a previous version of rspec and
autotest that when a set of specs passed for some changed files, that
all
of the specs would then be run automatically. Particularly when tests
had
previously failed. It’s not doing it now on trunk. Was I imagining this,
or is something wrong?

Thanks,
Steve

On Sat, 16 Feb 2008 10:23:53 -0500, David C. wrote:

On Feb 15, 2008 6:06 PM, Steve
[email protected] wrote:

I seem to remember when I was running a previous version of rspec and
autotest that when a set of specs passed for some changed files, that
all of the specs would then be run automatically. Particularly when
tests had previously failed. It’s not doing it now on trunk. Was I
imagining this, or is something wrong?

Something was wrong, but it’s fixed now in trunk.

What was the nature of the changes. I just updated to r3312, and when I
run autotest I get:

loading autotest/rails_rspec
/usr/bin/ruby1.8 -S script/spec -O spec/spec.opts
No server is running

I’ve never seen the “No server is running” message before.

Steve

On Feb 15, 2008 6:06 PM, Steve [email protected] wrote:

I seem to remember when I was running a previous version of rspec and
autotest that when a set of specs passed for some changed files, that all
of the specs would then be run automatically. Particularly when tests had
previously failed. It’s not doing it now on trunk. Was I imagining this,
or is something wrong?

Something was wrong, but it’s fixed now in trunk.

On Sat, 16 Feb 2008 18:13:51 +0000, Steve wrote:

What was the nature of the changes. I just updated to r3312, and when I
run autotest I get:

loading autotest/rails_rspec
/usr/bin/ruby1.8 -S script/spec -O spec/spec.opts No
server is running

I’ve never seen the “No server is running” message before.

Cancel that. I had --drb in spec.opts, and it looks like there was a
commit to make that work. Funny I never noticed that before.

On Sat, Feb 16, 2008 at 10:39 AM, David C. [email protected]
wrote:

Cancel that. I had --drb in spec.opts, and it looks like there was a
commit to make that work. Funny I never noticed that before.

It was broken until a recent changeset :slight_smile:

I don’t think it’s working quite right.

‘A puzzle if rejected, when resaved, should be re-submitted’ FAILED
expected rejected? to return true, got false
/Users/joe/projects/tanga/vendor/plugins/rspec/lib/spec/expectations.rb:52:in
fail_with' /Users/joe/projects/tanga/vendor/plugins/rspec/lib/spec/expectations/handler.rb:21:in handle_matcher’
/Users/joe/projects/tanga/vendor/plugins/rspec/lib/spec/expectations/extensions/object.rb:34:in
`should’
./spec/models/puzzle_spec.rb:187:

Then this is the next executation:
ruby -S script/spec -O spec/spec.opts spec/models/puzzle_spec.rb
/Users/joe/projects/tanga/vendor/plugins/rspec/lib/spec/expectations.rb

So it thiks that some rspec file was the cause of the crash. If the
exception was raised from inside the Rails framework, then it tries to
re-run the Rails file, and that sometimes really messes things up.

Joe

On Feb 16, 2008 1:21 PM, Steve [email protected] wrote:

Cancel that. I had --drb in spec.opts, and it looks like there was a
commit to make that work. Funny I never noticed that before.

It was broken until a recent changeset :slight_smile:

On Wed, Feb 20, 2008 at 10:41 PM, Joe Van D. [email protected]
wrote:

I’ve never seen the “No server is running” message before.
expected rejected? to return true, got false
/Users/joe/projects/tanga/vendor/plugins/rspec/lib/spec/expectations.rb

So it thiks that some rspec file was the cause of the crash. If the
exception was raised from inside the Rails framework, then it tries to
re-run the Rails file, and that sometimes really messes things up.

What rspec revision?

On Thu, Feb 21, 2008 at 5:21 AM, David C. [email protected]
wrote:

server is running

Then this is the next executation:
ruby -S script/spec -O spec/spec.opts spec/models/puzzle_spec.rb
/Users/joe/projects/tanga/vendor/plugins/rspec/lib/spec/expectations.rb

So it thiks that some rspec file was the cause of the crash. If the
exception was raised from inside the Rails framework, then it tries to
re-run the Rails file, and that sometimes really messes things up.

What rspec revision?

trunk as of yesterday.