On Jan 11, 2008, at 5:54 PM, Ben Mabey <[EMAIL PROTECTED]> wrote:
> David Chelimsky wrote:
>>
>>
>> In TDD there is a rule of thumb that says don't stub a method in the
>> same class as the method you're testing. The risk is that as the real
>> implementation of by_input_sets!() changes over tim
On Jan 11, 2008 12:56 PM, Cody P. Skidmore <[EMAIL PROTECTED]> wrote:
> Thank you Zach. I was just about to ask about this. I'm just getting
> started with restful_authentication and have missed the context of your
> point. restful_authentication is such a huge improvement over what I'm
> use to
Thank you Zach. I was just about to ask about this. I'm just getting
started with restful_authentication and have missed the context of your
point. restful_authentication is such a huge improvement over what I'm
use to.
Could you elaborate just a little on the use context in controllers? Is
th
To add, all of our managers return LoginResult objects which contain
methods like:
- successful?
- user
- message
In the controller our code will look like:
if login.successful?
self.current_user = login.user
else
flash[:error] = login.message
end
This has worked well because it allows e
We pass the required items in as method arguments. In the spirit of
sharing code and getting people to review code. Here is our current
LoginManager:
class LoginManager
include Injection
inject :invitation_manager
def login_from_cookie(cookies, session)
CookieLoginManager.new(
:co
Zach Dennis wrote:
> On Jan 11, 2008 11:56 AM, David Chelimsky <[EMAIL PROTECTED]> wrote:
>
>> On Jan 11, 2008 9:54 AM, Ben Mabey <[EMAIL PROTECTED]> wrote:
>>
>>> David Chelimsky wrote:
>>>
In TDD there is a rule of thumb that says don't stub a method in the
same class as
On Jan 11, 2008 11:40 AM, Zach Dennis <[EMAIL PROTECTED]> wrote:
> On Jan 11, 2008 11:56 AM, David Chelimsky <[EMAIL PROTECTED]> wrote:
> > On Jan 11, 2008 9:54 AM, Ben Mabey <[EMAIL PROTECTED]> wrote:
> > > David Chelimsky wrote:
> > > >
> > > >
> > > > In TDD there is a rule of thumb that says do
On Jan 11, 2008 11:56 AM, David Chelimsky <[EMAIL PROTECTED]> wrote:
> On Jan 11, 2008 9:54 AM, Ben Mabey <[EMAIL PROTECTED]> wrote:
> > David Chelimsky wrote:
> > >
> > >
> > > In TDD there is a rule of thumb that says don't stub a method in the
> > > same class as the method you're testing. The r
On Jan 11, 2008 9:54 AM, Ben Mabey <[EMAIL PROTECTED]> wrote:
> David Chelimsky wrote:
> >
> >
> > In TDD there is a rule of thumb that says don't stub a method in the
> > same class as the method you're testing. The risk is that as the real
> > implementation of by_input_sets!() changes over time,
David Chelimsky wrote:
>
>
> In TDD there is a rule of thumb that says don't stub a method in the
> same class as the method you're testing. The risk is that as the real
> implementation of by_input_sets!() changes over time, it has access to
> internal state that could impact the behaviour of deco
On Jan 11, 2008 5:23 AM, David Chelimsky <[EMAIL PROTECTED]> wrote:
> On Jan 11, 2008 3:49 AM, Shot (Piotr Szotkowski) <[EMAIL PROTECTED]> wrote:
> > Daniel Tenner:
> >
> > > Might be a personal thing, but my approach is that I try to test the
> > > public behaviour of the object. Testing private m
On Jan 11, 2008 8:04 AM, Shot (Piotr Szotkowski) <[EMAIL PROTECTED]> wrote:
> David Chelimsky:
>
> > On Jan 11, 2008 3:49 AM, Shot (Piotr Szotkowski) <[EMAIL PROTECTED]> wrote:
>
> >> One run of by_input_sets!() takes a couple of seconds, so can
> >> be tested; one run of decompose!() takes much lo
David Chelimsky:
> On Jan 11, 2008 3:49 AM, Shot (Piotr Szotkowski) <[EMAIL PROTECTED]> wrote:
>> One run of by_input_sets!() takes a couple of seconds, so can
>> be tested; one run of decompose!() takes much longer, so to test
>> decompose!() I should stub by_input_sets!() so it returns canned
>
On Jan 11, 2008 3:49 AM, Shot (Piotr Szotkowski) <[EMAIL PROTECTED]> wrote:
> Daniel Tenner:
>
> > Might be a personal thing, but my approach is that I try to test the
> > public behaviour of the object. Testing private methods is, imho,
> > getting dangerously close to specifying how the object do
Daniel Tenner:
> Might be a personal thing, but my approach is that I try to test the
> public behaviour of the object. Testing private methods is, imho,
> getting dangerously close to specifying how the object does its
> business, rather than what it does.
I agree on principle, but I ran into th
Yes, you're absolutely right. I somehow ignored the class name in my
previous answers, but that would have been the next point of attack. ;-)
Pat Maddox schrieb:
> On Jan 10, 2008 12:34 PM, Francois Wurmus <[EMAIL PROTECTED]> wrote:
>> Even my suggestion wouldn't be a sufficient spec. What abou
On Jan 10, 2008 12:34 PM, Francois Wurmus <[EMAIL PROTECTED]> wrote:
> Even my suggestion wouldn't be a sufficient spec. What about completely
> wrong mac addresses? Empty addresses, too many characters, invalid
> characters?
I just sent a reply that crossed wires with yours...anyway,
introducing
On Jan 10, 2008 12:25 PM, Jarkko Laine <[EMAIL PROTECTED]> wrote:
> Also, this line of code is a bit smelly:
>
> >> normalized = @signup.normalize_mac(@signup.mac_address)
>
> Since normalize_mac is an instance method in the Signup class, there's
> no point passing the mac_address as a paramet
Even my suggestion wouldn't be a sufficient spec. What about completely
wrong mac addresses? Empty addresses, too many characters, invalid
characters?
It is not for nothing that the rspec test cases are called examples -
you may define any number of example inputs and expected outputs that
are
On 10.1.2008, at 22.21, Francois Wurmus wrote:
> Apart from private or public methods I see a problem in your test
> case.
> You don't make sure that your mac_address is returned in exactly the
> way
> you want - you are merely saying it should look like the return
> value of
> some (protec
Apart from private or public methods I see a problem in your test case.
You don't make sure that your mac_address is returned in exactly the way
you want - you are merely saying it should look like the return value of
some (protected) method you call (normalize_mac).
Let's assume this method was
It's interesting that this thread has started because I just ran into
this problem.
The error I got was:
NoMethodError in 'Signup she be a valid mac address'
protected method `normalize_mac' called for #
./spec/models/signup_spec.rb:10:
Here's the spec:
describe Signup do
before(:each) do
On Jan 9, 2008 5:26 AM, Richard Conroy <[EMAIL PROTECTED]> wrote:
> On Jan 8, 2008 7:14 PM, Daniel Tenner <[EMAIL PROTECTED]> wrote:
> > Might be a personal thing, but my approach is that I try to test the
> > public behaviour of the object. Testing private methods is, imho,
> > getting dangerously
On Jan 8, 2008 11:25 AM, Matt Patterson <[EMAIL PROTECTED]> wrote:
> On 8 Jan 2008, at 19:14, Daniel Tenner wrote:
>
>
> > Might be a personal thing, but my approach is that I try to test the
> > public behaviour of the object. Testing private methods is, imho,
> > getting dangerously close to spec
On Jan 8, 2008 3:56 PM, Francois Wurmus <[EMAIL PROTECTED]> wrote:
> Chris Olsen schrieb:
> > Will obj.send(:method) work in 1.9 or is it saying that the send call
> > requires 2 params, the method and the object reference?
> >
> obj.send(:method) will work for non-private methods and send! works f
This is also worth checking out:
http://xunitpatterns.com/
--
Bekk Open Source
http://boss.bekk.no
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
On Jan 9, 2008 7:26 AM, Richard Conroy <[EMAIL PROTECTED]> wrote:
> On Jan 8, 2008 7:14 PM, Daniel Tenner <[EMAIL PROTECTED]> wrote:
> > Might be a personal thing, but my approach is that I try to test the
> > public behaviour of the object. Testing private methods is, imho,
> > getting dangerously
On Jan 8, 2008 7:14 PM, Daniel Tenner <[EMAIL PROTECTED]> wrote:
> Might be a personal thing, but my approach is that I try to test the
> public behaviour of the object. Testing private methods is, imho,
> getting dangerously close to specifying how the object does its
> business, rather than what
On Jan 9, 2008 7:12 AM, Stefan Magnus Landrø <[EMAIL PROTECTED]> wrote:
>
> 2008/1/9, Kerry Buckley < [EMAIL PROTECTED]>:
>
> > On Jan 9, 2008 10:01 AM, Stefan Magnus Landrø < [EMAIL PROTECTED]>
> wrote:
> > > I totally agree with you, David!
> > >
> > > For quite a while I was testing all my metho
On Jan 9, 2008 6:09 AM, Kerry Buckley <[EMAIL PROTECTED]> wrote:
> On Jan 9, 2008 10:01 AM, Stefan Magnus Landrø <[EMAIL PROTECTED]> wrote:
> > I totally agree with you, David!
Then you agree with the majority of the TDD community.
> >
> > For quite a while I was testing all my methods (even had
Well, I think it all depends on the scenario - but in a lot of cases it
should absolutely be considered a code-smell.
Stefan
2008/1/9, Kerry Buckley <[EMAIL PROTECTED]>:
>
> On Jan 9, 2008 10:01 AM, Stefan Magnus Landrø <[EMAIL PROTECTED]>
> wrote:
> > I totally agree with you, David!
> >
> > For
On Jan 9, 2008 10:01 AM, Stefan Magnus Landrø <[EMAIL PROTECTED]> wrote:
> I totally agree with you, David!
>
> For quite a while I was testing all my methods (even had to declare them
> protected/package scope in java!), but I realized that I was getting into a
> lot of trouble. Now I've shifted t
Just to clarify, this is what I meant in my original email :-) Most
of my methods are very small - in Ruby any method longer than 5 lines
is, imho, a code smell that's waiting to be fixed. However, no matter
how many methods are used to implement the functionality, I test the
public behavio
I totally agree with you, David!
For quite a while I was testing all my methods (even had to declare them
protected/package scope in java!), but I realized that I was getting into a
lot of trouble. Now I've shifted to testing functionality in stead of
methods.
Now, sometimes you might end up havi
obj.send(:method) will work for non-private methods and send! works for
private methods.
additionally there is send() without a receiving object. that is the
only of those methods requiring two parameters.
Chris Olsen schrieb:
> Will obj.send(:method) work in 1.9 or is it saying that the send
On Jan 8, 2008 1:25 PM, Matt Patterson <[EMAIL PROTECTED]> wrote:
> On 8 Jan 2008, at 19:14, Daniel Tenner wrote:
>
>
> > Might be a personal thing, but my approach is that I try to test the
> > public behaviour of the object. Testing private methods is, imho,
> > getting dangerously close to speci
The send call never expects an object reference as a parameter. Either
it is called on an object or without an object context (i.e. kernel). In
the first case the parameter should contain one of the receiving
object's methods. In the second case the parameter is a kernel method.
But... that's n
On Jan 8, 2008 2:47 PM, Chris Olsen <[EMAIL PROTECTED]> wrote:
> Will obj.send(:method) work in 1.9 or is it saying that the send call
> requires 2 params, the method and the object reference?
In 1.9 you can say obj.send!(:method) even if :method is private.
obj.send(:method) will not work for pri
Will obj.send(:method) work in 1.9 or is it saying that the send call
requires 2 params, the method and the object reference?
--
Posted via http://www.ruby-forum.com/.
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman
Well there we go, Ben's method still stands :)
Tim
On Jan 8, 2008, at 12:36 PM, Ben Mabey wrote:
> Yes. http://eigenclass.org/hiki/Changes+in+Ruby+1.9#l24
>
> Tim Harper wrote:
>> Doesn't 1.9 allow you to call obj.send!, which will allow you to
>> access private methods?
>>
>> Tim
>>
>> On Ja
Yes. http://eigenclass.org/hiki/Changes+in+Ruby+1.9#l24
Tim Harper wrote:
> Doesn't 1.9 allow you to call obj.send!, which will allow you to
> access private methods?
>
> Tim
>
> On Jan 8, 2008, at 12:27 PM, Scott Taylor wrote:
>
>
>> On Jan 8, 2008, at 2:20 PM, Ben Mabey wrote:
>>
>>
>
Doesn't 1.9 allow you to call obj.send!, which will allow you to
access private methods?
Tim
On Jan 8, 2008, at 12:27 PM, Scott Taylor wrote:
>
> On Jan 8, 2008, at 2:20 PM, Ben Mabey wrote:
>
>> Chris Olsen wrote:
>>> How does a person test private methods?
>>>
>>> Is there a way to declare t
On Jan 8, 2008, at 2:20 PM, Ben Mabey wrote:
> Chris Olsen wrote:
>> How does a person test private methods?
>>
>> Is there a way to declare them as private, but retain any tests that
>> were written during the initial development?
>>
>> Thanks.
>>
> When I need to do this I just use the send met
On 8 Jan 2008, at 19:14, Daniel Tenner wrote:
> Might be a personal thing, but my approach is that I try to test the
> public behaviour of the object. Testing private methods is, imho,
> getting dangerously close to specifying how the object does its
> business, rather than what it does.
>
If yo
Chris Olsen wrote:
> How does a person test private methods?
>
> Is there a way to declare them as private, but retain any tests that
> were written during the initial development?
>
> Thanks.
>
When I need to do this I just use the send method.
-Ben
Might be a personal thing, but my approach is that I try to test the
public behaviour of the object. Testing private methods is, imho,
getting dangerously close to specifying how the object does its
business, rather than what it does.
I would just spec the externally visible behaviour, where
On 8 Jan 2008, at 18:39, Chris Olsen wrote:
> How does a person test private methods?
>
> Is there a way to declare them as private, but retain any tests that
> were written during the initial development?
I'm rather liking Jay Field's approach (described at http://
blog.jayfields.com/2007/11/ru
How does a person test private methods?
Is there a way to declare them as private, but retain any tests that
were written during the initial development?
Thanks.
--
Posted via http://www.ruby-forum.com/.
___
rspec-users mailing list
rspec-users@rubyfor
48 matches
Mail list logo
