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
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)
end
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
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 =
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
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 wolfma...@gmail.com wrote:
I am trying to upgrade a
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 dchelim...@gmail.com wrote:
On Jan 13, 2011, at 12:36 PM, Kurt wrote:
Hi -- Thanks for sharing all your
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
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
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
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
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 w...@wincent.com wrote:
El 02/02/2011, a las 02:28,
14 matches
Mail list logo
