I am trying to deploy my rails3 application in a production
environment. But when i run my first rake task:
RAILS_ENV=production rake db:setup
i always get the following result:
rake aborted!
uninitialized constant RSpec
and then points to the line in the Rakefile where it says
Whoops. Found it! I have a rcov.rake inside my lib/tasks like this:
desc "Run all specs with rcov"
RSpec::Core::RakeTask.new("test_cov") do |t|
t.rcov = true
t.rcov_opts = %w{--rails --include views --exclude gems\/,spec
\/,features\/,seeds\/}
end
Now i am looking for a clean way to disable
On Sep 13, 3:58 am, nathanvda wrote:
> Whoops. Found it! I have a rcov.rake inside my lib/tasks like this:
>
> desc "Run all specs with rcov"
> RSpec::Core::RakeTask.new("test_cov") do |t|
> t.rcov = true
> t.rcov_opts = %w{--rails --include views --exclude gems\/,spec
> \/,features\/,seeds
On Sep 13, 1:01 am, Justin Ko wrote:
> On Sep 13, 3:58 am, nathanvda wrote:
>
>
>
>
>
> > Whoops. Found it! I have a rcov.rake inside my lib/tasks like this:
>
> > desc "Run all specs with rcov"
> > RSpec::Core::RakeTask.new("test_cov") do |t|
> > t.rcov = true
> > t.rcov_opts = %w{--rails -
Good evening,
I'm having some issues with the view specs on a project newly upgraded
from rspec-rails-1.2.x to rspec-rails-1.3.2, and also having had a
Rails upgrade from 2.3.5 to 2.3.9 done at the same time.
My view specs are now failing with messages like the one at the bottom
of this message.
I'm new to RSpec and came across an interesting situation where
calling a stubbed method with different parameters from those
specified, raises a misleading error. Some code to illustrate:
(rspec 1.3.0)
describe Person do
describe "#greeting" do
context "using #stub with correct parameters" do
I'm missing something in my setup of rspec-rails in a rails 3
project. I've included the link to the gist. It seems that it
doesn't recognize rails routes for some reason...getting "undefined
local variable or method". The spec file I'm running is sitting in
spec/integration, if that matters. T
It seems that rspec doesn't support passing a block to a stub method.
This code fails:
def call_build_with_block(o)
o.build do
puts "hello"
end
end
describe "call_build_with_block" do
it "should call build with block" do
o = double("object")
o.should_receive(:build) do |&b|
I'm working with a subclass of ActiveResource and I came across this
oddity when trying to stub its find method. Occurring with rspec
1.3.0:
The spec code looks like:
[1,2].each {|id|
Hive::CategoryResource.should_receive(:find).with(id).and_raise(ActiveResource::ResourceNotFound)}
Hive::Category
I'm trying to test that a view was rendered with a given layout. How
can I test which layout was used for the call to render() ?
The call that I want to test looks like this:
render :some_view, :layout => 'some_layout'
Thanks!
Lowell
___
rspec-users
Hi, I'm Takumi Tsunokake.
I think
expect { ... }.not_to rails_error
is more grammatical and natural than
expect { ... }.to_not rails_error
Are there any backgrounds and reasons of decision for expect
{ ... }.to_not, not expect { ... }.not_to?
I'm happy if expect { ... }.to_not is changed
After updating to Rails 3 and Rspec-rails 2.0, the tasks defined in
rspec.rake do not work anymore. I instead get this, even when running
the rake tasks via 'bundle exec':
* You are trying to run an rspec rake task defined in
* /Users/bessieandkyle/code/listsite/lib/tasks/rspec.rake,
* but rsp
Hello,
It looks like you started your integration spec with "context". Try
starting it (top level) with "describe". Think of context as "setting
the context for what you are describing".
Let us know if that fixes it.
On Sep 9, 1:46 pm, Lee Smith wrote:
> I'm missing something in my setup of rsp
On Sep 7, 2010, at 10:35 PM, Takumi Tsunokake wrote:
> Hi, I'm Takumi Tsunokake.
>
> I think
>expect { ... }.not_to rails_error
> is more grammatical and natural than
>expect { ... }.to_not rails_error
I think you mean raise_error (I've made the same mistake a few times). I'm
pretty sur
On Sep 13, 2010, at 5:30 PM, Michael Xavier wrote:
> I'm working with a subclass of ActiveResource and I came across this
> oddity when trying to stub its find method. Occurring with rspec
> 1.3.0:
>
> The spec code looks like:
>
> [1,2].each {|id|
> Hive::CategoryResource.should_receive(:find).
On Sep 9, 2010, at 4:52 PM, Lowell wrote:
> I'm trying to test that a view was rendered with a given layout. How
> can I test which layout was used for the call to render() ?
>
> The call that I want to test looks like this:
>
> render :some_view, :layout => 'some_layout'
response.should rende
On Sep 8, 2010, at 7:18 AM, Kyle wrote:
> After updating to Rails 3 and Rspec-rails 2.0, the tasks defined in
> rspec.rake
Delete it. rspec-rails-2 keeps the rake tasks in a file in the gem.
HTH,
David
> do not work anymore. I instead get this, even when running
> the rake tasks via 'bundle ex
On Sep 13, 2010, at 5:32 PM, nicolas wrote:
> It seems that rspec doesn't support passing a block to a stub method.
> This code fails:
>
> def call_build_with_block(o)
> o.build do
>puts "hello"
> end
> end
>
>
> describe "call_build_with_block" do
> it "should call build with block" do
On Sep 13, 6:32 pm, nicolas wrote:
> It seems that rspec doesn't support passing a block to a stub method.
> This code fails:
>
> def call_build_with_block(o)
> o.build do
> puts "hello"
> end
> end
>
> describe "call_build_with_block" do
> it "should call build with block" do
> o =
I'm new to RSpec and came across an interesting situation where
calling a stubbed method with different parameters from those
specified, raises a misleading error. Some code to illustrate:
(rspec 1.3.0)
describe Person do
describe "#greeting" do
context "using #stub with correct parameters"
I'm new to RSpec and came across an interesting situation where
calling a stubbed method with different parameters from those
specified, raises a misleading error. Some code to illustrate:
(rspec 1.3.0)
describe Person do
describe "#greeting" do
context "using #stub with correct parameters" d
Hey, rspec 2 upgrade question.
Rspec 1.x had a class hierarchy. In a Rails project, the ExampleGroup
inherited from Test::Unit::TestCase.
That allowed me to set use_transactional_fixtures in my own
ExampleGroups and rely on inheritance for the settings to propagate.
Now it seems like RSpec::Core:
describe 'I want this to be inherited' do
before do
RSpec.configure {|c| c.use_transactional_fixtures = false }
end
context 'blah' do
I would wrap it in a method if you're doing it often.
On Sep 14, 12:31 am, Brian Takita wrote:
> Hey, rspec 2 upgrade question.
>
> Rspec 1.x had a cla
23 matches
Mail list logo
