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
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
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
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
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
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
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
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
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
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
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
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
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:
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_
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
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
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
17 matches
Mail list logo
