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