On Aug 27, 8:18 pm, Myron Marston wrote:
> One of the primary dangers of using mocks is that your unit tests may
> be testing against an interface that is different from that of your
> production objects. You may simply have misspelled the method (e.g.
> object.should_receive(:methd_name) rathe
On Aug 27, 8:44 pm, Justin Ko wrote:
> On Aug 27, 4:12 pm, Daniel Lidström wrote:
>
>
>
>
>
> > Hello,
>
> > I am trying to run my first integration tests of my rails 3
> > application. All tests fail with an error "stack level too deep". The
> > tests are intended to verify the link routes and
> What defines a "concrete object"?
> Anything that is not an RSpec stub object?
Yep, that's how I'm using the term. It doesn't make sense to do a
respond_to? check on a pure mock or stub object, since it doesn't
initially have a defined interface (outside of the interface of
Object).
___
On Aug 27, 4:12 pm, Daniel Lidström wrote:
> Hello,
>
> I am trying to run my first integration tests of my rails 3
> application. All tests fail with an error "stack level too deep". The
> tests are intended to verify the link routes and look like this:
>
> dan...@ubuntu/home/daniel/programming
On Aug 27, 8:24 pm, Justin Ko wrote:
> On Aug 27, 8:18 pm, Myron Marston wrote:
>
>
>
>
>
> > One of the primary dangers of using mocks is that your unit tests may
> > be testing against an interface that is different from that of your
> > production objects. You may simply have misspelled the
On Aug 27, 8:18 pm, Myron Marston wrote:
> One of the primary dangers of using mocks is that your unit tests may
> be testing against an interface that is different from that of your
> production objects. You may simply have misspelled the method (e.g.
> object.should_receive(:methd_name) rathe
One of the primary dangers of using mocks is that your unit tests may
be testing against an interface that is different from that of your
production objects. You may simply have misspelled the method (e.g.
object.should_receive(:methd_name) rather than method_name), or you
may have changed the int
> One assertion per test [1] is a good rule of thumb, but don't get too hung up
> about it.
To rephrase this slightly, you should test one behavior per spec, and
having multiple assertions or expectations in the same test is a good
sign that you may be testing multiple behaviors.
On Aug 27, 2010, at 1:36 AM, Justin Ko wrote:
> The "best practice" in your situation is to have two specs like so:
>
> describe "#deposit" do
> it 'adds $10 to a savings account' do
>user.bank.deposit(10)
>user.bank.deposit.saving.should == 10
> end
>
> it 'creates a deposit record'
This is how I do it:
before { sign_in(user_record) }
describe "#index" do
before do
controller.current_user.stub(:orders) { ... }
end
it "..." do
get :index
end
end
Hope that helps.
On Aug 24, 7:51 pm, Titinux wrote:
> Hello,
>
> I'm new in using RSpec and I can't figured out
The "best practice" in your situation is to have two specs like so:
describe "#deposit" do
it 'adds $10 to a savings account' do
user.bank.deposit(10)
user.bank.deposit.saving.should == 10
end
it 'creates a deposit record' do
user.bank.deposit(10)
user.deposit_record.should
Well, you could setup a default parameter hash:
describe MyController do
let(:params) { {:format => 'js'} }
describe '#show' do
it '...' do
get :show, params.merge(:id => 1)
end
end
end
You could also take it another level:
describe MyController do
let(:params) { {:format
One thing I notice is you have "get '/'" yet you don't have a root
route. You can define a root route like so:
root :to => "pages#home"
Also, you can run your requests by doing "rake spec:requests"
On Aug 27, 4:12 pm, Daniel Lidström wrote:
> Hello,
>
> I am trying to run my first integration t
Hello,
I am trying to run my first integration tests of my rails 3
application. All tests fail with an error "stack level too deep". The
tests are intended to verify the link routes and look like this:
dan...@ubuntu/home/daniel/programming/rails_projects/sample_app$ cat
spec/requests/layout_links
Hi Zhenning,
One assertion per test [1] is a good rule of thumb, but don't get too hung up
about it.
[1] http://blog.jayfields.com/2007/06/testing-one-assertion-per-test.html
On 27 Aug 2010, at 06:43, Zhenning Guan wrote:
> in real world, when user deposit money into their bank, bank have mone
both rake spec and spec itself expect a spec file to be named *_spec.rb, not
*.spec
On Fri, Aug 27, 2010 at 12:42 PM, theLemcke wrote:
> I have an unusual problem. I'm adding test coverage to my project,
> and I'd like to be able to run "rake spec" to run all the tests in
> the /spec folder of
I have an unusual problem. I'm adding test coverage to my project,
and I'd like to be able to run "rake spec" to run all the tests in
the /spec folder of the app, but whenever I use the commands "spec
spec" or "rake spec" I get no return value (rubymine returns "no tests
found" if I use that). Ho
On Aug 27, 2010, at 8:48 AM, Brennon Bortz wrote:
> On 27 Aug 2010, at 14:44, David Chelimsky wrote:
>
>> On Aug 27, 2010, at 8:37 AM, Brennon Bortz wrote:
>>
>>> On 27 Aug 2010, at 14:29, Brennon Bortz wrote:
>>>
On 27 Aug 2010, at 14:06, David Chelimsky wrote:
> On Aug 27, 201
On 27 Aug 2010, at 14:44, David Chelimsky wrote:
> On Aug 27, 2010, at 8:37 AM, Brennon Bortz wrote:
>
>> On 27 Aug 2010, at 14:29, Brennon Bortz wrote:
>>
>>> On 27 Aug 2010, at 14:06, David Chelimsky wrote:
>>>
On Aug 27, 2010, at 6:47 AM, Brennon Bortz wrote:
> Not sure what I
On Aug 27, 2010, at 8:37 AM, Brennon Bortz wrote:
> On 27 Aug 2010, at 14:29, Brennon Bortz wrote:
>
>> On 27 Aug 2010, at 14:06, David Chelimsky wrote:
>>
>>> On Aug 27, 2010, at 6:47 AM, Brennon Bortz wrote:
>>>
Not sure what I must have bumped, but autotest won't run any specs--only
>>
And now (I haven't touched anything...seriously!), even "AUTOFEATURE=false
autotest" gives me an endless loop of spec tests...
On 27 Aug 2010, at 14:29, Brennon Bortz wrote:
> Strange...that does work, but now autotest seems caught in an infinite loop.
> When I run autospec, the specs run, the
Strange...that does work, but now autotest seems caught in an infinite loop.
When I run autospec, the specs run, then the features, then the features
again...and again...and again...and so on. If I run autotest as follows:
"AUTOFEATURE=false autotest", I don't have the problem. Any other idea
On Aug 27, 2010, at 5:35 AM, Titinux wrote:
> I tink it's @orders should be an array of orders from
> current_user.orders.
>
> describe OrdersController do
> include Devise::TestHelpers
>
> def mock_order(stubs={})
>@mock_order ||= mock_model(Order, stubs).as_null_object
> end
>
> desc
On Aug 27, 2010, at 6:47 AM, Brennon Bortz wrote:
> Not sure what I must have bumped, but autotest won't run any specs--only
> features. No errors are given on startup. I've taken "export
> AUTOFEATURE=true" out of my ./bashrc file--now I just get a blank screen when
> running autotest. Addi
I should point out that autotest detects changes to specs just fine and reloads
accordingly--but still only gives blank output.
Thanks again,
Brennon
Brennon Bortz
Software Researcher
Dundalk Institute of Technology
brennon.bo...@casala.ie
Ph.D. Researcher & Composer - Sonic Arts Research Centre
Not sure what I must have bumped, but autotest won't run any specs--only
features. No errors are given on startup. I've taken "export
AUTOFEATURE=true" out of my ./bashrc file--now I just get a blank screen when
running autotest. Adding "export RSPEC=true" to .bashrc doesn't change
anything
I tink it's @orders should be an array of orders from
current_user.orders.
describe OrdersController do
include Devise::TestHelpers
def mock_order(stubs={})
@mock_order ||= mock_model(Order, stubs).as_null_object
end
describe "GET index" do
it "assigns user's orders to @orders" d
27 matches
Mail list logo
