I think that's one of the nicest descriptions of the value of outside-in
I've seen.
Thanks Zach.
2008/9/5 Zach Dennis <[EMAIL PROTECTED]>
> On Thu, Sep 4, 2008 at 7:14 PM, Nick Hoffman <[EMAIL PROTECTED]> wrote:
> > On 2008-08-27, at 15:25, Mark Wilden wrote:
> >>
> >> The other thing I would sa
Ben and Pat, your descriptions, explanations, and examples were
awesome. I'm beginning to see why and how mocks and stubs are useful,
and when they should be used. As I mentioned to Mark and Zach, I'm
going to take a couple of days to re-read all of your emails and have
this info settle, tr
* Pain when mocking usually points to potential design improvements
+1
It's all about Behaviour Driven *Design*.
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
On Thu, Sep 4, 2008 at 4:14 PM, Nick Hoffman <[EMAIL PROTECTED]> wrote:
> On 2008-08-27, at 15:25, Mark Wilden wrote:
>>
>> The other thing I would say is that mocking and stubbing are powerful
>> tools that you should add to your arsenal as soon as possible. I've had
>> several coworkers who resis
Nick Hoffman wrote:
> On 2008-08-27, at 15:25, Mark Wilden wrote:
>> The other thing I would say is that mocking and stubbing are powerful
>> tools that you should add to your arsenal as soon as possible. I've
>> had several coworkers who resisted using them, only to finally
>> achieve that "aha!"
Mark and Zach, you both posed great perspectives and gave great
explanations. Thanks for taking the time to write all of that. I'm
going to re-read your emails several times over the next couple of
days and see how the info percolates into my brain. I may even rewrite
my current specs using
On Thu, Sep 4, 2008 at 7:14 PM, Nick Hoffman <[EMAIL PROTECTED]> wrote:
> On 2008-08-27, at 15:25, Mark Wilden wrote:
>>
>> The other thing I would say is that mocking and stubbing are powerful
>> tools that you should add to your arsenal as soon as possible. I've had
>> several coworkers who resis
On Thu, Sep 4, 2008 at 4:14 PM, Nick Hoffman <[EMAIL PROTECTED]> wrote:
> However, I'm not a fan of mocking and stubbing, primarily for two reasons:
> 1) I believe that specs should test behaviour, rather than a behaviour's
> implementation.
"Behavior" (to me) means "what it does." "What it doe
On 2008-08-27, at 15:25, Mark Wilden wrote:
The other thing I would say is that mocking and stubbing are
powerful tools that you should add to your arsenal as soon as
possible. I've had several coworkers who resisted using them, only
to finally achieve that "aha!" moment later. Your tests ge
So, that was a great response to my questions. Thanks a lot, guys.
Nick,
Thanks for your help and your suggestions and your time.
The articles you linked to were helpful, no doubt.
Pat,
I realize now that you're the guy I first heard about story runner from
with your screencast on it.
I think I
On 28 Aug 2008, at 04:46, Scott Taylor wrote:
Especially regressions. Usually you can get in a few extra specs
when writing a regression that has nothing to do with the bug
itself (it's a sort of testing after the fact - almost like proving
theorems of an existing system).
The Feathers bo
On Aug 27, 2008, at 2:40 PM, Matt Wynne wrote:
I have another, more general tip - read this book:
http://www.amazon.com/Working-Effectively-Legacy-Robert-Martin/dp/0131177052
Michael's definition of Legacy Code is simply 'code that isn't
covered by tests'. So... err... that would be your who
I'll just second the other suggestions of a) getting some high-level
integration tests over the app; b) doing the detailed specs
just-in-time when you need to make a change; and c) reading Michael
Feathers' book. I've been in the same position, and the above three
points helped a lot.
--
Avdi
H
On Wed, Aug 27, 2008 at 10:20 AM, Lake Denman <[EMAIL PROTECTED]> wrote:
> def upgrade(payment)
>transaction do
> payment.user_id = self.id
> payment.payment_type = Payment::SUBSCRIPTION_PAYMENT_TYPE
> return false unless (payment.save and payment.external_id)
> self.subsc
I have another, more general tip - read this book:
http://www.amazon.com/Working-Effectively-Legacy-Robert-Martin/dp/
0131177052
Michael's definition of Legacy Code is simply 'code that isn't
covered by tests'. So... err... that would be your whole app!
The book suggests chipping away at th
On Wed, Aug 27, 2008 at 1:20 PM, Lake Denman <[EMAIL PROTECTED]> wrote:
> The project has been written - around 10,000 lines of code, but
> certainly less than that to add tests to. There has been no official
> testing put into place, and I'd very much like to implement RSpec into
> the project for
On 2008-08-27, at 13:20, Lake Denman wrote:
For a visual guide:
def upgrade(payment)
transaction do
payment.user_id = self.id
payment.payment_type = Payment::SUBSCRIPTION_PAYMENT_TYPE
return false unless (payment.save and payment.external_id)
self.subscription_id = payment
The project has been written - around 10,000 lines of code, but
certainly less than that to add tests to. There has been no official
testing put into place, and I'd very much like to implement RSpec into
the project for a few reasons, but mostly to setup solid examples for
the behavior of the appli
18 matches
Mail list logo
