hey, thanks for reading:
I have a problem which can be reduced to this,
from within an example of mine I call the helper 'expect_call' which is
defined thus:
def expect_call(*hash*)*
*obj.should_receive(:some_
method).with(*hash*)*
*end
and in one of my examples the 'expected' hash is strictl
On Feb 1, 2011, at 3:40 AM, James OBrien wrote:
> hey, thanks for reading:
>
> I have a problem which can be reduced to this,
>
> from within an example of mine I call the helper 'expect_call' which is
> defined thus:
>
> def expect_call(hash)
> obj.should_receive(:some_
> method).with(hash
additionally,
since my
*foo.should_receive(...
*expectation
*
*is actually in a private helper method ('expect_call') on the example group
I will need to pull this code up into a block, since not all callers pass a
hash with :some_key set
viz:
#helper_method
*def expect_call
foo.should_recei
ooops, that sent itself early...
. . .
there are other entries in the hash so presumably I will need something like
this
foo.should_receive(:bar) do |hash|
actual = hash[:some_key]
*hash[:some_key] = nil*
hash.should == {
:my => 'expected'
:other => 1
:ields => :in_
Awesome, thanks David!
there are other entries in the hash so presumably I will need something like
this
i.e.
foo.should_receive(:bar) do |hash|
actual = hash[:some_key]
hash[:some_key].should =~ [1,2,3]
hash.shoul
end
On Tue, Feb 1, 2011 at 4:43 AM, David Chelimsky wrote:
I've started a chart of differences between RSpec 1 and 2 here:
http://snyderscribbles.blogspot.com/2011/01/rspec-2-changes-from-rspec-1.html
I'll gladly post any new discoveries anyone want to contribute.
On Dec 4 2010, 3:22 pm, Jim Morris wrote:
> I am trying to upgrade a Rails 2.2.2app to Rai
Most of our RSpec2 conversion has been done since version 2.4, so my
report of performance 2-3 times slower than RSpec 1 is based on those
releases.
On Jan 13, 11:11 am, David Chelimsky wrote:
> On Jan 13, 2011, at 12:36 PM, Kurt wrote:
>
> > Hi -- Thanks for sharing all your tips. I couldn't un
When you're ready to try RSpec2 again, checkout this cheat sheet of changes
from RSpec1.
http://snyderscribbles.blogspot.com/2011/01/rspec-2-changes-from-rspec-1.html
We're adding to the list as people discover more...
___
rspec-users mailing list
rspe
On Feb 1, 2011, at 4:23 PM, Kurt wrote:
> I've started a chart of differences between RSpec 1 and 2 here:
> http://snyderscribbles.blogspot.com/2011/01/rspec-2-changes-from-rspec-1.html
>
> I'll gladly post any new discoveries anyone want to contribute.
It would be great if you would contribute
On Feb 1, 2011, at 4:31 PM, Kurt wrote:
> Most of our RSpec2 conversion has been done since version 2.4, so my
> report of performance 2-3 times slower than RSpec 1 is based on those
> releases.
Are you sure that's all RSpec? rspec-core-2.2 actually runs faster than
rspec-core-1.x, and a lot of
Does this strike anyone else as odd?
Don't you think the test should actually be written IN to the code itself?
I guess I'm soft of stipulating a new language here, but perhaps Ruby is
flexible enough to enable this.
Surely as the private methods of a class change, the testing code HAS to
chan
I don't fully understand this response..
The private method I mentioned was a helper created by me in test code on
the example group.
Still very interested
On Feb 1, 2011 7:28 PM, "Julian Leviston" wrote:
Does this strike anyone else as odd?
Don't you think the test should actually be written
Sorry it was a knee-jerk reaction that was prompted by what you wrote, but not
necessarily even connected to it.
Essentially, I've been wondering/thinking about this for a very long time
(since about 15 years ago when I started writing smalltalk code).
I think a general principle of code is tha
Sorry but I disagree.
Specs should define only the external behavior of an object or service -
allowing for confident implementation adjustments against a trusted suite of
tests.
What you're describing would make refactoring very hard. I think what you
say goes against a lot of established theory
El 02/02/2011, a las 02:28, Julian Leviston escribió:
> Surely as the private methods of a class change, the testing code HAS to
> change...
That statement sets off all sorts of alarm bells for me.
In order for your specs to be non-brittle, they should be concerned with the
externally-visible
On 02/02/2011, at 3:47 PM, Wincent Colaiuta wrote:
> El 02/02/2011, a las 02:28, Julian Leviston escribió:
>
>> Surely as the private methods of a class change, the testing code HAS to
>> change...
>
> That statement sets off all sorts of alarm bells for me.
>
> In order for your specs to be
I agree Vincent
Can people however please use this trail to help me with my original query.
I repeat the private method is declared on the test example group. This is
not inside implemenraton code.
On Feb 1, 2011 9:21 PM, "Wincent Colaiuta" wrote:
El 02/02/2011, a las 02:28, Julian Leviston es
17 matches
Mail list logo
