[rspec-users] Four Question From an RSpec Baby - Give me something to chew
matt at mattwynne.net
Wed Aug 27 14:40:12 EDT 2008
I have another, more general tip - read this book:
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 the lack of test coverage by
writing tests (or specs) when you
- change code to add a feature
- need to fix a bug (write a test / spec that fails because of the
bug... fix the bug... high five)
So rather than trying to tackle all 1000 lines of you user model at
once, you have some practical motivation. This is also a great habit
to get into for future work.
Working with legacy code is particularly tricky as it may be hard to
test, since it wasn't written with testing in mind. The book has some
great guidance in the techniques you can use to introduce 'seams'
between parts of the code that you'll need to test in isolation.
In case you wondered: The opinions expressed in this email are my own
and do not necessarily reflect the views of any former, current or
future employers of mine.
On 27 Aug 2008, at 19:25, Nick Hoffman wrote:
> 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.external_id
>> self.payment_id = payment.id
>> self.member = true
>> self.member_since = AppLib.today_utc
>> return true
> Hi Lake.
>> 1.) Do I need to use any mocking/stubbing in this example (or in Unit
> You need to use whatever you think is most suitable for your
> application. I'm sure many people on here would use mocks and stubs
> extensively throughout that method. For example, they might mock
> the entire "payment" object, and stub out AppLib.today_utc .
>> 2.) Is it wrong to access multiple objects (user and payment in my
>> example) in a Unit Test example?
> I don't think so, but I'm not a unit test expert.
>> 3.) Would you mind showing me an example of how you might implement a
>> spec for this method.
> User upgrade
> - can succeed if the payment amount is correct
> - fails if the payment amount is incorrect
> - can succeed if the payment type is valid
> - fails if the payment type if invalid
> I'm new to RSpec though, so there's probably a "better"/clearer/
> more efficient way of doing it.
>> 4.) Could you PLEASE PLEASE PLEASE guide me to a resource that helped
>> you the most with figuring out Unit Testing with RSpec. Not
>> limited to
>> books or blog posts... good source code examples might be helpful.
> Why not use BDD? =)
>> Hopefully you can see my sincere want to know more and I wish that a
>> simple "want" will blossom into a realization of a "need" to test
> Just search, read, try, and ask.
>> Thanks for any help you can provide me on my journey - I have a
>> long way
>> ahead of me.
> That doesn't answer all of your questions directly, but hopefully
> it'll be helpful in one way or another. Cheers,
> rspec-users mailing list
> rspec-users at rubyforge.org
More information about the rspec-users