[rspec-users] Four Question From an RSpec Baby - Give me something to chew

Matt Wynne 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
>>      self.save
>>      return true
>>    end
>>  end
> Hi Lake.
>> 1.) Do I need to use any mocking/stubbing in this example (or in Unit
>> Tests)
> 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
> etc..
> 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?  =)
> http://blog.davidchelimsky.net/articles/2007/05/14/an-introduction- 
> to-rspec-part-i
> http://blog.davidchelimsky.net/articles/2006/11/06/view-spec-tutorial
> http://blog.withoutincident.com/2007/5/29/blogification-part-ii- 
> rspec-bdd-and-authors
>> 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  
>> test
>> 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,
> Nick
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

More information about the rspec-users mailing list