Anyone seen weird autotest behaviour on trunk?

Testing RSpec
1

Hi

I’m running RSpec and RSpec on Rails r3333, and autotest frequently -
but
not consistently - fails on my after I change an individual model code
file
file.

The error I get is this:
/usr/local/bin/ruby -S script/spec -O spec/spec.opts
spec/models/user_spec.rb
/home/amoran/Documents/becta/apps/Backend/app/models/user.rb
/home/amoran/Documents/becta/apps/Backend/app/models/user.rb:4:
uninitialized constant ActiveRecord (NameError)

Any idea what could be going wrong?

Ashley

2

On 31-mrt-2008, at 17:32, Ashley M. wrote:

/home/amoran/Documents/becta/apps/Backend/app/models/user.rb:4:
uninitialized constant ActiveRecord (NameError)

I’m having the same problem, also with controllers. Weird part is, I
mostly have it at work, running OS 10.4, but not at home, running
10.5. My environment is the same, except for the OS…

gr,
bartz

3

On 31/03/2008, Bart Z. [email protected] wrote:

I’m having the same problem, also with controllers. Weird part is, I
mostly have it at work, running OS 10.4, but not at home, running
10.5. My environment is the same, except for the OS…

gr,
bartz

Hi bartz

What version of RSpec are you using at work and home? (I am using
Ubuntu at
work BTW.)

Ashley

4

On 31-mrt-2008, at 18:22, Ashley M. wrote:

What version of RSpec are you using at work and home? (I am using
Ubuntu at work BTW.)

According to ‘svn up’, it’s revision 3333 for both rspec and
rspec_on_rails. Both at home and at work.

5

On Tue, 2008-04-01 at 08:48 +0100, Ashley M. wrote:

Hmm, exact same revision as me. Are we the only one s having
problems? I’ve also noticed errors along the lines of
“ActionController not found” and “expected XXX to respond to
respond_to?” (or something - that from the developer that sits behind
me).

We are seeing the exact same thing with Zentest 3.9.2 and RSpec 1.1.4.
The thing I noticed yesterday is that autotest seems to want to run the
model or controller directly instead of the spec file, just like in
Ashley’s original mail. Obviously this leads to an error because that
doesn’t load spec_helper which in turn doesn’t load the rails framework.
Presto: ActiveRecord has not been initialized.

The real question is: why is autotest running specs with the wrong
names? Did anyone resolve this yet?

Kind regards,

Hans

6

On 01/04/2008, Bart Z. [email protected] wrote:

According to ‘svn up’, it’s revision 3333 for both rspec and
rspec_on_rails. Both at home and at work.

Hmm, exact same revision as me. Are we the only one s having problems?
I’ve also noticed errors along the lines of “ActionController not found”
and
“expected XXX to respond to respond_to?” (or something - that from the
developer that sits behind me).

Would love to know what’s going on…

Ashley

7

On Wed, Jun 4, 2008 at 6:26 AM, Hans de Graaff [email protected]
wrote:

On Tue, 2008-04-01 at 08:48 +0100, Ashley M. wrote:

Hmm, exact same revision as me. Are we the only one s having
problems? I’ve also noticed errors along the lines of
“ActionController not found” and “expected XXX to respond to
respond_to?” (or something - that from the developer that sits behind
me).

We are seeing the exact same thing with Zentest 3.9.2 and RSpec 1.1.4.

Oh thank goodness, it’s not me. I am seeing the same kinds of
weirdness too, but only since I upgraded to Rails 2.1

I’m kinda new to RSpec so I wasn’t sure if it was something i was
doing. In the meantime I’ve been trying to figure out whether 1.1.4 is
the right version of RSpec to run against 2.1.

The thing I noticed yesterday is that autotest seems to want to run the
model or controller directly instead of the spec file, just like in
Ashley’s original mail. Obviously this leads to an error because that
doesn’t load spec_helper which in turn doesn’t load the rails framework.
Presto: ActiveRecord has not been initialized.

Ah, that makes sense.

The real question is: why is autotest running specs with the wrong
names? Did anyone resolve this yet?

One thing I’ve noticed is that it never seems to do it from a fresh
run (either when you start autotest or hit Ctrl+C), only when it
re-runs a changed spec. And not every time, only occasionally.

I’ve started running autotest with the -v option to try and figure out
what it’s doing.

Regards,

Matt

8

On Jun 4, 2008, at 3:26 AM, David C. wrote:

behind
is

I’ve started running autotest with the -v option to try and figure
out
what it’s doing.

I’ve got it figured out. Fix coming shortly (like in 10 minutes)

I believe this is now fixed in

.

If any of you can still reproduce this, please let me know.

Cheers,
David

9

On Wed, Jun 4, 2008 at 9:37 AM, David C. [email protected]
wrote:

I’ve got it figured out. Fix coming shortly (like in 10 minutes)

I believe this is now fixed in
make sure consolidate_failures only grabs _spec files. Closes #369 · dchelimsky/rspec@2b474ac · GitHub.

If any of you can still reproduce this, please let me know.

That’s quick work David, thanks :wink:

I’m still not entirely sure which version of rspec I should be running
for Rails 2.1. Is edge a reasonable safe choice? Should I stick with
1.1.4 and wait for 1.1.5. I’m not sure how to make this judgement.

Regards,

Matt

10

On Jun 4, 2008, at 3:20 AM, Matt M. wrote:

We are seeing the exact same thing with Zentest 3.9.2 and RSpec
the
names? Did anyone resolve this yet?

One thing I’ve noticed is that it never seems to do it from a fresh
run (either when you start autotest or hit Ctrl+C), only when it
re-runs a changed spec. And not every time, only occasionally.

I’ve started running autotest with the -v option to try and figure out
what it’s doing.

I’ve got it figured out. Fix coming shortly (like in 10 minutes)

11

On Jun 4, 2008, at 3:47 AM, Matt M. wrote:

That’s quick work David, thanks :wink:

I’m still not entirely sure which version of rspec I should be running
for Rails 2.1. Is edge a reasonable safe choice? Should I stick with
1.1.4 and wait for 1.1.5. I’m not sure how to make this judgement.

There is some broken story stuff in edge right now that will get fixed
in the next day or so. If you’re not using plain text stories, just
grab that.

You could always grab the repo, make a 1.1.4 branch and cherry pick
this commit.

git clone git://github.com/dchelimsky/rspec.git
git checkout -b 1.1.4
git cherry-pick 2b474ac78ad877c13d577490b16f4f3380944e83

Sadly there is a conflict in the CHANGES file, but it’s easily fixed.
After you resolve the conflict …

git add .
git commit -c 2b474ac

Cheers,
David

12

On Wed, 2008-06-04 at 03:37 -0500, David C. wrote:

I believe this is now fixed in make sure consolidate_failures only grabs _spec files. Closes #369 · dchelimsky/rspec@2b474ac · GitHub
.

If any of you can still reproduce this, please let me know.

I tracked this down on Wednesday to the same code. However, this patch
doesn’t quite fix the problem for us. In the backtrace output we also
have files without the closing semi-colon, and the regexp doesn’t catch
those. I’ve fixed this locally by not requiring the last semi-colon and
fix seems to work as expected again.

I’m not sure if this is the right fix, as it may also be a bug that the
last semi-colon is missing from the backtrace list?

Kind regards,

Hans

13

On Fri, 2008-06-06 at 08:12 -0500, David C. wrote:

On Jun 6, 2008, at 12:42 AM, Hans de Graaff wrote:

I’m not sure if this is the right fix, as it may also be a bug that
the
last semi-colon is missing from the backtrace list?

That could be from different versions of Ruby. I’m not sure there is
any harm in removing the second ‘:’ - does anybody else think there is?

FWIW I’m using ruby 1.8.6 pl 114 here.

Kind regards,

Hans

14

On Jun 6, 2008, at 12:42 AM, Hans de Graaff wrote:

catch
those. I’ve fixed this locally by not requiring the last semi-colon
and
fix seems to work as expected again.

I’m not sure if this is the right fix, as it may also be a bug that
the
last semi-colon is missing from the backtrace list?

That could be from different versions of Ruby. I’m not sure there is
any harm in removing the second ‘:’ - does anybody else think there is?