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
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
12 matches
Mail list logo
