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 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.

cheers,
Matt
----
http://blog.mattwynne.net
http://songkick.com

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@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Reply via email to