[This is my third and final attempt to post to this group, first 2 were with google groups] I noticed that focusing a single spec takes ages to run. We commonly use that, often in combination with guard to speed up our spec runs. I admit that the overall performance of our specs is bad, since we ditched mocking entirely and went with semi-integration specs on all levels. But this practice has served us very well on picking up failures. All runs on a single spec with focus: true that only tests (2 + 2).should == 4, among 700 other specs. Any ideas how to profile or even fix that? # What I want to get: $ time rspec spec/models/user_spec.rb:5 Finished in 1.41 seconds 1 example, 0 failures real 0m13.768s user 0m11.269s sys 0m1.692s # What I get using the focus tag: $ time rake spec Finished in 2.1 seconds 1 example, 0 failures real 1m5.502s user 0m46.467s sys 0m14.455s $time rspec spec Finished in 1.39 seconds 1 example, 0 failures real 0m51.350s user 0m36.069s sys 0m12.842s Thank you Ray -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20120606/cd57d0bc/attachment.html>
On Wed, Jun 6, 2012 at 5:14 AM, Rainer Kuhn <rainer at incutio.com> wrote:> [This is my third and final attempt to post to this group, first 2 were with > google groups]The google group is a mirror of the rspec-users list, but for that to work you actually have to post to the rspec-users list, not the google group. We''re considering retiring that list and only using the google group, at which point you''d be able to post directly to the google group.> I noticed that focusing a single spec takes ages to run. We commonly use > that, often in combination with guard to speed up our spec runs. I admit > that the overall performance of our specs is bad, since we ditched mocking > entirely and went with semi-integration specs on all levels. But this > practice has served us very well on picking up failures. > > All runs on a single spec with focus: true that only tests (2 + 2).should => 4, among 700 other specs. > Any ideas how to profile or even fix that? > > # What I want to get: > $ time rspec spec/models/user_spec.rb:5 > Finished in 1.41 seconds?1 example, 0 failures > real 0m13.768s > user 0m11.269s > sys 0m1.692sWow. This is _not_ what I''d want to get. Nearly 14 secs to run a single example sounds like you''re suffering some serious startup time. What version of rspec, ruby, rails, etc are you running?> # What I get using the focus tag: > $ time rake spec > Finished in 2.1 seconds?1 example, 0 failures > real 1m5.502s > user 0m46.467s > sys 0m14.455sWhen you run `rake spec` it loads up the Rails development environment (because that''s the environment you''re running rake in) and then shells out the `rspec spec` command with the Rails test environment. That''s why `rake spec` will always take longer than running `rspec spec`.> $time rspec spec > Finished in 1.39 seconds?1 example, 0 failures > real 0m51.350s > user 0m36.069s > sys 0m12.842sWhen you run with `--tag focus` on the command line, or `config.filter_run_including :focus`, rspec evaluates the metadata for every example in the suite in order to find the one(s) that match(es) the tag. It''s possible that you''ve got a filter in your config or in a spec that takes a long time to evaluate. What''s in RSpec.configure in spec/spec_helper.rb? David
I have started with a blank spec_helper and I''m seeing lots of improvements regarding the focus tag. Not the 12sec load time however. Let me do some legwork first and I present you with the results in a couple of hours. Tomorrow perhaps since I have a couple of hours of urgent dev work my list. My current spec_helper is a huge mess copy pasted from multiple sources over a period of 4 months. I''m really not proud of it especially since I''m using spec since 2008. Read it and weep: https://gist.github.com/2881400 On Wed, Jun 6, 2012 at 12:24 PM, David Chelimsky <dchelimsky at gmail.com>wrote:> On Wed, Jun 6, 2012 at 5:14 AM, Rainer Kuhn <rainer at incutio.com> wrote: > > [This is my third and final attempt to post to this group, first 2 were > with > > google groups] > > The google group is a mirror of the rspec-users list, but for that to > work you actually have to post to the rspec-users list, not the google > group. We''re considering retiring that list and only using the google > group, at which point you''d be able to post directly to the google > group. > > > I noticed that focusing a single spec takes ages to run. We commonly use > > that, often in combination with guard to speed up our spec runs. I admit > > that the overall performance of our specs is bad, since we ditched > mocking > > entirely and went with semi-integration specs on all levels. But this > > practice has served us very well on picking up failures. > > > > All runs on a single spec with focus: true that only tests (2 + > 2).should => > 4, among 700 other specs. > > Any ideas how to profile or even fix that? > > > > # What I want to get: > > $ time rspec spec/models/user_spec.rb:5 > > Finished in 1.41 seconds 1 example, 0 failures > > real 0m13.768s > > user 0m11.269s > > sys 0m1.692s > > Wow. This is _not_ what I''d want to get. Nearly 14 secs to run a > single example sounds like you''re suffering some serious startup time. > What version of rspec, ruby, rails, etc are you running? > > > # What I get using the focus tag: > > $ time rake spec > > Finished in 2.1 seconds 1 example, 0 failures > > real 1m5.502s > > user 0m46.467s > > sys 0m14.455s > > When you run `rake spec` it loads up the Rails development environment > (because that''s the environment you''re running rake in) and then > shells out the `rspec spec` command with the Rails test environment. > That''s why `rake spec` will always take longer than running `rspec > spec`. > > > $time rspec spec > > Finished in 1.39 seconds 1 example, 0 failures > > real 0m51.350s > > user 0m36.069s > > sys 0m12.842s > > When you run with `--tag focus` on the command line, or > `config.filter_run_including :focus`, rspec evaluates the metadata for > every example in the suite in order to find the one(s) that match(es) > the tag. It''s possible that you''ve got a filter in your config or in a > spec that takes a long time to evaluate. What''s in RSpec.configure in > spec/spec_helper.rb? > > David > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >-- Rainer Kuhn Rails Developer Incutio :: www.incutio.com http://www.facebook.com/Incutio https://twitter.com/incutio UK Head Office: Unit 4, The Bridge Business Centre, Ash Road South, Wrexham, LL13 9UG. US Head Office: 33 South Commercial Street, Manchester, NH 03101 T: +44 (0) 1978 661 666 F: +44 (0)7092 181 581 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20120606/3690f8dd/attachment-0001.html>
On Wed, Jun 6, 2012 at 6:38 AM, Rainer Kuhn <rainer at incutio.com> wrote:> I have started with a blank spec_helper and I''m seeing lots of improvements > regarding the focus tag. Not the 12sec load time however. Let me do some > legwork first and I present you with the results in a couple of hours. > Tomorrow perhaps since I have a couple of hours of urgent dev work my list. > > My current spec_helper is a huge mess copy pasted from multiple sources over > a period of 4 months. I''m really not proud of it especially since I''m using > spec since 2008. Read it and weep: > https://gist.github.com/2881400There''s a lot there. Redis, fog, all the macros modules. Any of them could be contributing.> On Wed, Jun 6, 2012 at 12:24 PM, David Chelimsky <dchelimsky at gmail.com> > wrote: >> >> On Wed, Jun 6, 2012 at 5:14 AM, Rainer Kuhn <rainer at incutio.com> wrote: >> > [This is my third and final attempt to post to this group, first 2 were >> > with >> > google groups] >> >> The google group is a mirror of the rspec-users list, but for that to >> work you actually have to post to the rspec-users list, not the google >> group. We''re considering retiring that list and only using the google >> group, at which point you''d be able to post directly to the google >> group. >> >> > I noticed that focusing a single spec takes ages to run. We commonly use >> > that, often in combination with guard to speed up our spec runs. I admit >> > that the overall performance of our specs is bad, since we ditched >> > mocking >> > entirely and went with semi-integration specs on all levels. But this >> > practice has served us very well on picking up failures. >> > >> > All runs on a single spec with focus: true that only tests (2 + >> > 2).should =>> > 4, among 700 other specs. >> > Any ideas how to profile or even fix that? >> > >> > # What I want to get: >> > $ time rspec spec/models/user_spec.rb:5 >> > Finished in 1.41 seconds?1 example, 0 failures >> > real 0m13.768s >> > user 0m11.269s >> > sys 0m1.692s >> >> Wow. This is _not_ what I''d want to get. Nearly 14 secs to run a >> single example sounds like you''re suffering some serious startup time. >> What version of rspec, ruby, rails, etc are you running? >> >> > # What I get using the focus tag: >> > $ time rake spec >> > Finished in 2.1 seconds?1 example, 0 failures >> > real 1m5.502s >> > user 0m46.467s >> > sys 0m14.455s >> >> When you run `rake spec` it loads up the Rails development environment >> (because that''s the environment you''re running rake in) and then >> shells out the `rspec spec` command with the Rails test environment. >> That''s why `rake spec` will always take longer than running `rspec >> spec`. >> >> > $time rspec spec >> > Finished in 1.39 seconds?1 example, 0 failures >> > real 0m51.350s >> > user 0m36.069s >> > sys 0m12.842s >> >> When you run with `--tag focus` on the command line, or >> `config.filter_run_including :focus`, rspec evaluates the metadata for >> every example in the suite in order to find the one(s) that match(es) >> the tag. It''s possible that you''ve got a filter in your config or in a >> spec that takes a long time to evaluate. What''s in RSpec.configure in >> spec/spec_helper.rb? >> >> David >> _______________________________________________ >> rspec-users mailing list >> rspec-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users > > > > > -- > Rainer Kuhn > > Rails Developer > Incutio ::?www.incutio.com > http://www.facebook.com/Incutio > https://twitter.com/incutio > > UK Head Office: Unit 4, The Bridge Business Centre, Ash Road South, Wrexham, > LL13 9UG. > > US Head Office:?33 South Commercial Street,?Manchester,?NH 03101 > > T:?+44 (0)?1978 661 666 > F:?+44 (0)7092 181 581 > > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users
I narrowed it down to three things, the first one might be interesting to
you, the other ones are my problem, although probably common among lots of
projects:
Since we don''t mock we usually need a bit of test data prepared for
each
test. At first we used factories, but setting things up every time took way
to long. So I went for fixture builder instead. (
http://pivotallabs.com/users/georg/blog/articles/1864-fixture-builder-and-rspec-acceptance)
It was an immediate improvement, although not a great one, since we have a
generic setup_test_data method that runs before most tests and loads from
the database into instance variables.
1) config.global_fixtures = :all
With this line in, the execution of a single focused spec jumps up to a
minute. My unresearched guess is that it might load the fixtures for each
spec, although it won''t even be executed.
2) They way I handle fixtures
I am about to change fixture loading to lazy evaluation instead
require ''rspec/core/shared_context''
module LazyFixtures
extend RSpec::Core::SharedContext
let(:admin) { User.first }
end
3) My Rails Env doesn''t exactly load fast
time rails runner "3 + 4"
real 0m11.521s
user 0m8.531s
sys 0m1.404s
(4) Not really relevant, but a Macbook Air runs out of it''s 4GB memory
so
fast and starts swapping, next time, I want an iMac!
On Wed, Jun 6, 2012 at 12:50 PM, David Chelimsky <dchelimsky at
gmail.com>wrote:
> On Wed, Jun 6, 2012 at 6:38 AM, Rainer Kuhn <rainer at incutio.com>
wrote:
> > I have started with a blank spec_helper and I''m seeing lots
of
> improvements
> > regarding the focus tag. Not the 12sec load time however. Let me do
some
> > legwork first and I present you with the results in a couple of hours.
> > Tomorrow perhaps since I have a couple of hours of urgent dev work my
> list.
> >
> > My current spec_helper is a huge mess copy pasted from multiple
sources
> over
> > a period of 4 months. I''m really not proud of it especially
since I''m
> using
> > spec since 2008. Read it and weep:
> > https://gist.github.com/2881400
>
> There''s a lot there. Redis, fog, all the macros modules. Any of
them
> could be contributing.
>
> > On Wed, Jun 6, 2012 at 12:24 PM, David Chelimsky <dchelimsky at
gmail.com>
> > wrote:
> >>
> >> On Wed, Jun 6, 2012 at 5:14 AM, Rainer Kuhn <rainer at
incutio.com> wrote:
> >> > [This is my third and final attempt to post to this group,
first 2
> were
> >> > with
> >> > google groups]
> >>
> >> The google group is a mirror of the rspec-users list, but for that
to
> >> work you actually have to post to the rspec-users list, not the
google
> >> group. We''re considering retiring that list and only
using the google
> >> group, at which point you''d be able to post directly to
the google
> >> group.
> >>
> >> > I noticed that focusing a single spec takes ages to run. We
commonly
> use
> >> > that, often in combination with guard to speed up our spec
runs. I
> admit
> >> > that the overall performance of our specs is bad, since we
ditched
> >> > mocking
> >> > entirely and went with semi-integration specs on all levels.
But this
> >> > practice has served us very well on picking up failures.
> >> >
> >> > All runs on a single spec with focus: true that only tests (2
+
> >> > 2).should => >> > 4, among 700 other specs.
> >> > Any ideas how to profile or even fix that?
> >> >
> >> > # What I want to get:
> >> > $ time rspec spec/models/user_spec.rb:5
> >> > Finished in 1.41 seconds 1 example, 0 failures
> >> > real 0m13.768s
> >> > user 0m11.269s
> >> > sys 0m1.692s
> >>
> >> Wow. This is _not_ what I''d want to get. Nearly 14 secs
to run a
> >> single example sounds like you''re suffering some serious
startup time.
> >> What version of rspec, ruby, rails, etc are you running?
> >>
> >> > # What I get using the focus tag:
> >> > $ time rake spec
> >> > Finished in 2.1 seconds 1 example, 0 failures
> >> > real 1m5.502s
> >> > user 0m46.467s
> >> > sys 0m14.455s
> >>
> >> When you run `rake spec` it loads up the Rails development
environment
> >> (because that''s the environment you''re running
rake in) and then
> >> shells out the `rspec spec` command with the Rails test
environment.
> >> That''s why `rake spec` will always take longer than
running `rspec
> >> spec`.
> >>
> >> > $time rspec spec
> >> > Finished in 1.39 seconds 1 example, 0 failures
> >> > real 0m51.350s
> >> > user 0m36.069s
> >> > sys 0m12.842s
> >>
> >> When you run with `--tag focus` on the command line, or
> >> `config.filter_run_including :focus`, rspec evaluates the metadata
for
> >> every example in the suite in order to find the one(s) that
match(es)
> >> the tag. It''s possible that you''ve got a filter
in your config or in a
> >> spec that takes a long time to evaluate. What''s in
RSpec.configure in
> >> spec/spec_helper.rb?
> >>
> >> David
> >> _______________________________________________
> >> rspec-users mailing list
> >> rspec-users at rubyforge.org
> >> http://rubyforge.org/mailman/listinfo/rspec-users
> >
> >
> >
> >
> > --
> > Rainer Kuhn
> >
> > Rails Developer
> > Incutio :: www.incutio.com
> > http://www.facebook.com/Incutio
> > https://twitter.com/incutio
> >
> > UK Head Office: Unit 4, The Bridge Business Centre, Ash Road South,
> Wrexham,
> > LL13 9UG.
> >
> > US Head Office: 33 South Commercial Street, Manchester, NH 03101
> >
> > T: +44 (0) 1978 661 666
> > F: +44 (0)7092 181 581
> >
> >
> > _______________________________________________
> > rspec-users mailing list
> > rspec-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-users
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
--
Rainer Kuhn
Rails Developer
Incutio :: www.incutio.com
http://www.facebook.com/Incutio
https://twitter.com/incutio
UK Head Office: Unit 4, The Bridge Business Centre, Ash Road South,
Wrexham, LL13 9UG.
US Head Office: 33 South Commercial Street, Manchester, NH 03101
T: +44 (0) 1978 661 666
F: +44 (0)7092 181 581
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20120607/da8c7f1c/attachment.html>
On Thu, Jun 7, 2012 at 4:00 AM, Rainer Kuhn <rainer at incutio.com> wrote:> I narrowed it down to three things, the first one might be interesting to > you, the other ones are my problem, although probably common among lots of > projects: > > Since we don''t mock we usually need a bit of test data prepared for each > test. At first we used factories, but setting things up every time took way > to long. So I went for fixture builder instead. > (http://pivotallabs.com/users/georg/blog/articles/1864-fixture-builder-and-rspec-acceptance) > It was an immediate improvement, although not a great one, since we have a > generic setup_test_data method that runs before most tests and loads from > the database into instance variables. > > 1)?config.global_fixtures = :all > With this line in, the execution of a single focused spec jumps up to a > minute. My unresearched guess is that it might load the fixtures for each > spec, although it won''t even be executed.Would you please check log/test.log to verify this?
On Thu, Jun 7, 2012 at 5:54 AM, David Chelimsky <dchelimsky at gmail.com> wrote:> On Thu, Jun 7, 2012 at 4:00 AM, Rainer Kuhn <rainer at incutio.com> wrote: >> I narrowed it down to three things, the first one might be interesting to >> you, the other ones are my problem, although probably common among lots of >> projects: >> >> Since we don''t mock we usually need a bit of test data prepared for each >> test. At first we used factories, but setting things up every time took way >> to long. So I went for fixture builder instead. >> (http://pivotallabs.com/users/georg/blog/articles/1864-fixture-builder-and-rspec-acceptance) >> It was an immediate improvement, although not a great one, since we have a >> generic setup_test_data method that runs before most tests and loads from >> the database into instance variables. >> >> 1)?config.global_fixtures = :all >> With this line in, the execution of a single focused spec jumps up to a >> minute. My unresearched guess is that it might load the fixtures for each >> spec, although it won''t even be executed. > > Would you please check log/test.log to verify this?Actually I went ahead and checked this myself and what I see is that it only creates fixtures before each spec that is run. If you run one, it happens once ... 2, twice, etc.
My guess was wrong, it can''t seem to handle empty fixtures yml files.
The
gist contains only a brief snippets of the actual log, but you can see that
it''s trying to load fixtures from multiple specs
https://gist.github.com/2888253
cat event_critical_errors.yml
--- {}
Users/rainer/work/app_path/spec/controllers/accounts_controller_spec.rb:3:in
`<top (required)>''
Unable to load event_critical_error, underlying cause No such file to load
-- event_critical_error
/Users/rainer/work/carrier-pigeon/spec/requests/suppressed_emails_spec.rb:3:in
`<top (required)>''
Unable to load event_critical_error, underlying cause No such file to load
-- event_critical_error
If you need more data, let me know.
On Thu, Jun 7, 2012 at 11:54 AM, David Chelimsky <dchelimsky at
gmail.com>wrote:
> On Thu, Jun 7, 2012 at 4:00 AM, Rainer Kuhn <rainer at incutio.com>
wrote:
> > I narrowed it down to three things, the first one might be interesting
to
> > you, the other ones are my problem, although probably common among
lots
> of
> > projects:
> >
> > Since we don''t mock we usually need a bit of test data
prepared for each
> > test. At first we used factories, but setting things up every time
took
> way
> > to long. So I went for fixture builder instead.
> > (
>
http://pivotallabs.com/users/georg/blog/articles/1864-fixture-builder-and-rspec-acceptance
> )
> > It was an immediate improvement, although not a great one, since we
have
> a
> > generic setup_test_data method that runs before most tests and loads
from
> > the database into instance variables.
> >
> > 1) config.global_fixtures = :all
> > With this line in, the execution of a single focused spec jumps up to
a
> > minute. My unresearched guess is that it might load the fixtures for
each
> > spec, although it won''t even be executed.
>
> Would you please check log/test.log to verify this?
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
--
Rainer Kuhn
Rails Developer
Incutio :: www.incutio.com
http://www.facebook.com/Incutio
https://twitter.com/incutio
UK Head Office: Unit 4, The Bridge Business Centre, Ash Road South,
Wrexham, LL13 9UG.
US Head Office: 33 South Commercial Street, Manchester, NH 03101
T: +44 (0) 1978 661 666
F: +44 (0)7092 181 581
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20120607/7ad9f085/attachment.html>
I guess I can forward this issue to fixture builder, It only happens for fixtures that are in a module, like Event::Confirm Event::CriticalError Those fixtures propably need to either be named differently or to live in a module subfolder. So, nothing wrong with RSpec, I am very sorry that I put this one on you, so many times you have already proven to people that the error lies elsewhere and rspec is running perfectly fine. But for many users like me it''s where we see the error/problem we suspect it''s origin. And integration between all the testing tools is tricky to balance for devs. On Thu, Jun 7, 2012 at 12:15 PM, David Chelimsky <dchelimsky at gmail.com>wrote:> On Thu, Jun 7, 2012 at 5:54 AM, David Chelimsky <dchelimsky at gmail.com> > wrote: > > On Thu, Jun 7, 2012 at 4:00 AM, Rainer Kuhn <rainer at incutio.com> wrote: > >> I narrowed it down to three things, the first one might be interesting > to > >> you, the other ones are my problem, although probably common among lots > of > >> projects: > >> > >> Since we don''t mock we usually need a bit of test data prepared for each > >> test. At first we used factories, but setting things up every time took > way > >> to long. So I went for fixture builder instead. > >> ( > http://pivotallabs.com/users/georg/blog/articles/1864-fixture-builder-and-rspec-acceptance > ) > >> It was an immediate improvement, although not a great one, since we > have a > >> generic setup_test_data method that runs before most tests and loads > from > >> the database into instance variables. > >> > >> 1) config.global_fixtures = :all > >> With this line in, the execution of a single focused spec jumps up to a > >> minute. My unresearched guess is that it might load the fixtures for > each > >> spec, although it won''t even be executed. > > > > Would you please check log/test.log to verify this? > > Actually I went ahead and checked this myself and what I see is that > it only creates fixtures before each spec that is run. If you run one, > it happens once ... 2, twice, etc. > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >-- Rainer Kuhn Rails Developer Incutio :: www.incutio.com http://www.facebook.com/Incutio https://twitter.com/incutio UK Head Office: Unit 4, The Bridge Business Centre, Ash Road South, Wrexham, LL13 9UG. US Head Office: 33 South Commercial Street, Manchester, NH 03101 T: +44 (0) 1978 661 666 F: +44 (0)7092 181 581 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20120607/acb27593/attachment.html>
Follow up: is there a way to set RSpec to be less forgiving on errors. If my specs would have failed because of that error I would have fixed it months ago. (Or at least reported it) On Thu, Jun 7, 2012 at 12:26 PM, Rainer Kuhn <rainer at incutio.com> wrote:> I guess I can forward this issue to fixture builder, It only happens for > fixtures that are in a module, like > Event::Confirm > Event::CriticalError > Those fixtures propably need to either be named differently or to live in > a module subfolder. > > So, nothing wrong with RSpec, I am very sorry that I put this one on you, > so many times you have already proven to people that the error lies > elsewhere and rspec is running perfectly fine. But for many users like me > it''s where we see the error/problem we suspect it''s origin. > And integration between all the testing tools is tricky to balance for > devs. > > On Thu, Jun 7, 2012 at 12:15 PM, David Chelimsky <dchelimsky at gmail.com>wrote: > >> On Thu, Jun 7, 2012 at 5:54 AM, David Chelimsky <dchelimsky at gmail.com> >> wrote: >> > On Thu, Jun 7, 2012 at 4:00 AM, Rainer Kuhn <rainer at incutio.com> wrote: >> >> I narrowed it down to three things, the first one might be interesting >> to >> >> you, the other ones are my problem, although probably common among >> lots of >> >> projects: >> >> >> >> Since we don''t mock we usually need a bit of test data prepared for >> each >> >> test. At first we used factories, but setting things up every time >> took way >> >> to long. So I went for fixture builder instead. >> >> ( >> http://pivotallabs.com/users/georg/blog/articles/1864-fixture-builder-and-rspec-acceptance >> ) >> >> It was an immediate improvement, although not a great one, since we >> have a >> >> generic setup_test_data method that runs before most tests and loads >> from >> >> the database into instance variables. >> >> >> >> 1) config.global_fixtures = :all >> >> With this line in, the execution of a single focused spec jumps up to a >> >> minute. My unresearched guess is that it might load the fixtures for >> each >> >> spec, although it won''t even be executed. >> > >> > Would you please check log/test.log to verify this? >> >> Actually I went ahead and checked this myself and what I see is that >> it only creates fixtures before each spec that is run. If you run one, >> it happens once ... 2, twice, etc. >> _______________________________________________ >> rspec-users mailing list >> rspec-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users >> > > > > -- > Rainer Kuhn > > Rails Developer > Incutio :: www.incutio.com > http://www.facebook.com/Incutio > https://twitter.com/incutio > > UK Head Office: Unit 4, The Bridge Business Centre, Ash Road South, > Wrexham, LL13 9UG. > > US Head Office: 33 South Commercial Street, Manchester, NH 03101 > > T: +44 (0) 1978 661 666 > F: +44 (0)7092 181 581 > >-- Rainer Kuhn Rails Developer Incutio :: www.incutio.com http://www.facebook.com/Incutio https://twitter.com/incutio UK Head Office: Unit 4, The Bridge Business Centre, Ash Road South, Wrexham, LL13 9UG. US Head Office: 33 South Commercial Street, Manchester, NH 03101 T: +44 (0) 1978 661 666 F: +44 (0)7092 181 581 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20120607/df0ef159/attachment-0001.html>
On Thu, Jun 7, 2012 at 6:17 AM, Rainer Kuhn <rainer at incutio.com> wrote:> My guess was wrong, it can''t seem to handle empty fixtures yml files. The > gist contains only a brief snippets of the actual log, but you can see that > it''s trying to load fixtures from multiple specs > > https://gist.github.com/2888253 > > cat event_critical_errors.yml > --- {} > > Users/rainer/work/app_path/spec/controllers/accounts_controller_spec.rb:3:in > `<top (required)>'' > Unable to load event_critical_error, underlying cause No such file to load > -- event_critical_error > > /Users/rainer/work/carrier-pigeon/spec/requests/suppressed_emails_spec.rb:3:in > `<top (required)>'' > Unable to load event_critical_error, underlying cause No such file to load > -- event_critical_errorThat''s happening in Rails. Would you please report this to http://github.com/rails/rails/issues?
On Thu, Jun 7, 2012 at 6:26 AM, Rainer Kuhn <rainer at incutio.com> wrote:> I guess I can forward this issue to fixture builder, It only happens for > fixtures that are in a module, like > Event::Confirm > Event::CriticalError > Those fixtures propably need to either be named differently or to live in a > module subfolder. > > So, nothing wrong with RSpec, I am very sorry that I put this one on you, so > many times you have already proven to people that the error lies elsewhere > and rspec is running perfectly fine. But for many users like me it''s where > we see the error/problem we suspect it''s origin.Don''t worry about blame, as long as you''re not spewing hate in the process. RSpec is far from perfect, and it''s fine for you to report problems here even if they end up being further down the stack. It''s useful for other RSpec users who might encounter the same problem, and once we identify what the problem really is then it can be reported to the proper place with more accuracy.> And integration between all the testing tools is tricky to balance for devs.This is true of non-testing tools as well :) Thanks for doing the research. Cheers, David> > On Thu, Jun 7, 2012 at 12:15 PM, David Chelimsky <dchelimsky at gmail.com> > wrote: >> >> On Thu, Jun 7, 2012 at 5:54 AM, David Chelimsky <dchelimsky at gmail.com> >> wrote: >> > On Thu, Jun 7, 2012 at 4:00 AM, Rainer Kuhn <rainer at incutio.com> wrote: >> >> I narrowed it down to three things, the first one might be interesting >> >> to >> >> you, the other ones are my problem, although probably common among lots >> >> of >> >> projects: >> >> >> >> Since we don''t mock we usually need a bit of test data prepared for >> >> each >> >> test. At first we used factories, but setting things up every time took >> >> way >> >> to long. So I went for fixture builder instead. >> >> >> >> (http://pivotallabs.com/users/georg/blog/articles/1864-fixture-builder-and-rspec-acceptance) >> >> It was an immediate improvement, although not a great one, since we >> >> have a >> >> generic setup_test_data method that runs before most tests and loads >> >> from >> >> the database into instance variables. >> >> >> >> 1)?config.global_fixtures = :all >> >> With this line in, the execution of a single focused spec jumps up to a >> >> minute. My unresearched guess is that it might load the fixtures for >> >> each >> >> spec, although it won''t even be executed. >> > >> > Would you please check log/test.log to verify this? >> >> Actually I went ahead and checked this myself and what I see is that >> it only creates fixtures before each spec that is run. If you run one, >> it happens once ... 2, twice, etc. >> _______________________________________________ >> rspec-users mailing list >> rspec-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users > > > > > -- > Rainer Kuhn > > Rails Developer > Incutio ::?www.incutio.com > http://www.facebook.com/Incutio > https://twitter.com/incutio > > UK Head Office: Unit 4, The Bridge Business Centre, Ash Road South, Wrexham, > LL13 9UG. > > US Head Office:?33 South Commercial Street,?Manchester,?NH 03101 > > T:?+44 (0)?1978 661 666 > F:?+44 (0)7092 181 581 > > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users
On Thu, Jun 7, 2012 at 6:29 AM, Rainer Kuhn <rainer at incutio.com> wrote:> Follow up: is there a way to set RSpec to be less forgiving on errors. If my > specs would have failed because of that error I would have fixed it months > ago. (Or at least reported it)I can''t duplicate this behavior myself, but from what I can see in the gist, it happens when rspec calls Rails `fixtures` method and does not bubble back up to RSpec. If you see a place that RSpec is actively hiding this please submit an issue to http://github.com/rspec/rspec-rails/issues. Cheers, David> > > On Thu, Jun 7, 2012 at 12:26 PM, Rainer Kuhn <rainer at incutio.com> wrote: >> >> I guess I can forward this issue to fixture builder, It only happens for >> fixtures that are in a module, like >> Event::Confirm >> Event::CriticalError >> Those fixtures propably need to either be named differently or to live in >> a module subfolder. >> >> So, nothing wrong with RSpec, I am very sorry that I put this one on you, >> so many times you have already proven to people that the error lies >> elsewhere and rspec is running perfectly fine. But for many users like me >> it''s where we see the error/problem we suspect it''s origin. >> And integration between all the testing tools is tricky to balance for >> devs. >> >> On Thu, Jun 7, 2012 at 12:15 PM, David Chelimsky <dchelimsky at gmail.com> >> wrote: >>> >>> On Thu, Jun 7, 2012 at 5:54 AM, David Chelimsky <dchelimsky at gmail.com> >>> wrote: >>> > On Thu, Jun 7, 2012 at 4:00 AM, Rainer Kuhn <rainer at incutio.com> wrote: >>> >> I narrowed it down to three things, the first one might be interesting >>> >> to >>> >> you, the other ones are my problem, although probably common among >>> >> lots of >>> >> projects: >>> >> >>> >> Since we don''t mock we usually need a bit of test data prepared for >>> >> each >>> >> test. At first we used factories, but setting things up every time >>> >> took way >>> >> to long. So I went for fixture builder instead. >>> >> >>> >> (http://pivotallabs.com/users/georg/blog/articles/1864-fixture-builder-and-rspec-acceptance) >>> >> It was an immediate improvement, although not a great one, since we >>> >> have a >>> >> generic setup_test_data method that runs before most tests and loads >>> >> from >>> >> the database into instance variables. >>> >> >>> >> 1)?config.global_fixtures = :all >>> >> With this line in, the execution of a single focused spec jumps up to >>> >> a >>> >> minute. My unresearched guess is that it might load the fixtures for >>> >> each >>> >> spec, although it won''t even be executed. >>> > >>> > Would you please check log/test.log to verify this? >>> >>> Actually I went ahead and checked this myself and what I see is that >>> it only creates fixtures before each spec that is run. If you run one, >>> it happens once ... 2, twice, etc. >>> _______________________________________________ >>> rspec-users mailing list >>> rspec-users at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/rspec-users >> >> >> >> >> -- >> Rainer Kuhn >> >> Rails Developer >> Incutio ::?www.incutio.com >> http://www.facebook.com/Incutio >> https://twitter.com/incutio >> >> UK Head Office: Unit 4, The Bridge Business Centre, Ash Road South, >> Wrexham, LL13 9UG. >> >> US Head Office:?33 South Commercial Street,?Manchester,?NH 03101 >> >> T:?+44 (0)?1978 661 666 >> F:?+44 (0)7092 181 581 >> > > > > -- > Rainer Kuhn > > Rails Developer > Incutio ::?www.incutio.com > http://www.facebook.com/Incutio > https://twitter.com/incutio > > UK Head Office: Unit 4, The Bridge Business Centre, Ash Road South, Wrexham, > LL13 9UG. > > US Head Office:?33 South Commercial Street,?Manchester,?NH 03101 > > T:?+44 (0)?1978 661 666 > F:?+44 (0)7092 181 581 > > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users
I tried putting the fixtures into a subfolder, next I''m trying to replicate the behaviour in a blank project. Then you and the rails devs have a bit more to play with. On Thu, Jun 7, 2012 at 12:57 PM, David Chelimsky <dchelimsky at gmail.com>wrote:> On Thu, Jun 7, 2012 at 6:29 AM, Rainer Kuhn <rainer at incutio.com> wrote: > > Follow up: is there a way to set RSpec to be less forgiving on errors. > If my > > specs would have failed because of that error I would have fixed it > months > > ago. (Or at least reported it) > > I can''t duplicate this behavior myself, but from what I can see in the > gist, it happens when rspec calls Rails `fixtures` method and does not > bubble back up to RSpec. If you see a place that RSpec is actively > hiding this please submit an issue to > http://github.com/rspec/rspec-rails/issues. > > Cheers, > David > > > > > > > On Thu, Jun 7, 2012 at 12:26 PM, Rainer Kuhn <rainer at incutio.com> wrote: > >> > >> I guess I can forward this issue to fixture builder, It only happens for > >> fixtures that are in a module, like > >> Event::Confirm > >> Event::CriticalError > >> Those fixtures propably need to either be named differently or to live > in > >> a module subfolder. > >> > >> So, nothing wrong with RSpec, I am very sorry that I put this one on > you, > >> so many times you have already proven to people that the error lies > >> elsewhere and rspec is running perfectly fine. But for many users like > me > >> it''s where we see the error/problem we suspect it''s origin. > >> And integration between all the testing tools is tricky to balance for > >> devs. > >> > >> On Thu, Jun 7, 2012 at 12:15 PM, David Chelimsky <dchelimsky at gmail.com> > >> wrote: > >>> > >>> On Thu, Jun 7, 2012 at 5:54 AM, David Chelimsky <dchelimsky at gmail.com> > >>> wrote: > >>> > On Thu, Jun 7, 2012 at 4:00 AM, Rainer Kuhn <rainer at incutio.com> > wrote: > >>> >> I narrowed it down to three things, the first one might be > interesting > >>> >> to > >>> >> you, the other ones are my problem, although probably common among > >>> >> lots of > >>> >> projects: > >>> >> > >>> >> Since we don''t mock we usually need a bit of test data prepared for > >>> >> each > >>> >> test. At first we used factories, but setting things up every time > >>> >> took way > >>> >> to long. So I went for fixture builder instead. > >>> >> > >>> >> ( > http://pivotallabs.com/users/georg/blog/articles/1864-fixture-builder-and-rspec-acceptance > ) > >>> >> It was an immediate improvement, although not a great one, since we > >>> >> have a > >>> >> generic setup_test_data method that runs before most tests and loads > >>> >> from > >>> >> the database into instance variables. > >>> >> > >>> >> 1) config.global_fixtures = :all > >>> >> With this line in, the execution of a single focused spec jumps up > to > >>> >> a > >>> >> minute. My unresearched guess is that it might load the fixtures for > >>> >> each > >>> >> spec, although it won''t even be executed. > >>> > > >>> > Would you please check log/test.log to verify this? > >>> > >>> Actually I went ahead and checked this myself and what I see is that > >>> it only creates fixtures before each spec that is run. If you run one, > >>> it happens once ... 2, twice, etc. > >>> _______________________________________________ > >>> rspec-users mailing list > >>> rspec-users at rubyforge.org > >>> http://rubyforge.org/mailman/listinfo/rspec-users > >> > >> > >> > >> > >> -- > >> Rainer Kuhn > >> > >> Rails Developer > >> Incutio :: www.incutio.com > >> http://www.facebook.com/Incutio > >> https://twitter.com/incutio > >> > >> UK Head Office: Unit 4, The Bridge Business Centre, Ash Road South, > >> Wrexham, LL13 9UG. > >> > >> US Head Office: 33 South Commercial Street, Manchester, NH 03101 > >> > >> T: +44 (0) 1978 661 666 > >> F: +44 (0)7092 181 581 > >> > > > > > > > > -- > > Rainer Kuhn > > > > Rails Developer > > Incutio :: www.incutio.com > > http://www.facebook.com/Incutio > > https://twitter.com/incutio > > > > UK Head Office: Unit 4, The Bridge Business Centre, Ash Road South, > Wrexham, > > LL13 9UG. > > > > US Head Office: 33 South Commercial Street, Manchester, NH 03101 > > > > T: +44 (0) 1978 661 666 > > F: +44 (0)7092 181 581 > > > > > > _______________________________________________ > > rspec-users mailing list > > rspec-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-users > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >-- Rainer Kuhn Rails Developer Incutio :: www.incutio.com http://www.facebook.com/Incutio https://twitter.com/incutio UK Head Office: Unit 4, The Bridge Business Centre, Ash Road South, Wrexham, LL13 9UG. US Head Office: 33 South Commercial Street, Manchester, NH 03101 T: +44 (0) 1978 661 666 F: +44 (0)7092 181 581 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20120607/ed1eb0c8/attachment-0001.html>