I think between you and Marnen I've really discovered a lot of useful
things.
Now that I'm starting to find myself sold on Cuke and RSpec I'm
looking back on earlier today when I actually bought that book you
mention. I'm a huge fan of the pragprog guys and always find myself
looking towards their new books.
Whats more is, just 15 minutes ago I got my first feature to pass. I
was pulling that code from the machinist git page and after a while,
discovered the error with make and make_unsaved... The tutorial on
their wiki has a mistake it seems.
Feature: Manage Quotes
I want to create and manage quotes
Scenario: Quotes List
Given I have quotes with titles Threadmill, Trepan
When I go to the list of quotes
Then I should see "Threadmill"
And I should see "Trepan"
It only took a wee bit of fighting and determination but it's most
certainly a start.
Again, your guidance has been very much appreciated.
I'm still a little weak in the knowing-what-to-test when area but "not
testing the framework" seems so obvious now it almost hurts.
So now I have to learn what to test where... for example - looking at
the big picture (feature) then diving into rspec for the unit tests. I
still don't see the clear line. Also, from what I've read - to say its
controversial to leave out controller tests is an understatement of
understatements ... heh... It almost feels sinful to read it.
I'm going to start checking the cuke and rspec lists from now on - I
can definitely see how this has gotten way off topic for rails but I
most certainly thank you for the insight provided in light of that.
Looking back I'm surprised I didn't get any "go to the right group
cause we can't help you" responses.
Thanks again,
- FJM
On Aug 11, 11:03 pm, "s.ross" <[email protected]> wrote:
> Hello--
>
> I think you are asking a lot of good questions. I would direct you to
> the rspec and cukes Google Groups for a great in-depth discussion of
> all this stuff. Also, Pragmatic Programmers has a beta book called
> "The rSpec Book" (IIRC) and you can buy it and read the PDF. The final
> print copy (if you buy one) will be delivered when it is complete.
> This book covers both rSpec and Cucumber and shows a good division of
> responsibility between the two tools.
>
> As I am really sold on rSpec and Cucumber, this is kind of OT for the
> Rails list, but my recommendations are:
>
> - Don't try to re-test Rails. If there was a bug in
> validates_presence_of or has_many, it would probably be known.
> - Corollary: Test *your use* of Rails. So (e.g.) if you use
> validates_format_of, make sure your regex is right.
> - Work from the outside in. Describe a feature (Cucumber), make it
> fail, drive the feature out, diving into rSpec where unit tests will
> be of value.
> - [controversial] Don't write controller tests if you can avoid it.
> Write Cucumber features.
> - [less-controversial] Make your controllers so stupid-simple that you
> can unit-test your models and get good coverage.
> - Re-evaluate your progress as you do the red-green-refactor cycle for
> a while. What works for some won't work for all.
> - Keep your eyes open for what others are sharing about the tools you
> are using and new tools that also might help.
> - Absolutely, keep the big picture in sight: You aren't writing specs,
> features, or tests; you're writing an app.
>
> Good luck... a few more answers below:
>
> On Aug 11, 2009, at 6:52 PM, Frank J. Mattia wrote:
>
>
>
>
>
>
>
> > On Aug 11, 9:39 pm, Marnen Laibow-Koser <rails-mailing-l...@andreas-
> > s.net> wrote:
> >> Frank J. Mattia wrote:
>
> >> [...]
>
> >>> I've just ripped out all of my Test::Unit stuff
>
> >> That may or may not be good, depending on how much you had to rip
> >> out.
> >> Then again, you can always use your version control system to go
> >> back...
>
> >>> I am having a go at
> >>> starting fresh with RSpec, Cucumber and Machinist... Please
> >>> understand
> >>> that I've only been casually programming for the past 10 years as a
> >>> way to kill time and challenge myself. I have no formal training,
>
> >> Neither do I.
>
> >>> never wrote anything serious and the fact that I've written anything
> >>> at all that works is a blessing because before last week - I had
> >>> never
> >>> written a test in my life - let alone put any thought into testing
> >>> an
> >>> entire application.
>
> >> Hey, don't feel bad. I worked professionally as a programmer for
> >> years
> >> without a systematic testing approach.
>
> >>> TDD/BDD are both intriguing and believe me - I see
> >>> their advantages... I'm just very slow on the uptake right now. It's
> >>> not the way I'm used to programming **read that as "I've developed a
> >>> lot of bad habits on my own and now I want to break them the right
> >>> way**.
>
> >> OK.
>
> >>> SO.
>
> >>> The one thing that keeps coming back to haunt me is that no Factory
> >>> framework seems to let you test complete objects from the has_many
> >>> side of the association without doing some serious legwork.
>
> >> What are you talking about? What do you mean by testing from the
> >> has_many side?
>
> > In retrospect that was a bad choice of words. What I should of said
> > was, "make complete objects". Then again, I may not fully understand
> > what I'm trying to do... In which case, this may be a long, painful
> > road... err. I mean... labor of love.
>
> > From the machinist webpage.
>
> > ================
> > Other Associations
> > For has_many and has_and_belongs_to_many associations, ActiveRecord
> > insists that the object be saved before any associated objects can be
> > saved. That means ***you can't generate the associated objects from
> > within the blueprint.***
>
> > The simplest solution is to write a test helper:
>
> > def make_post_with_comments(attributes = {})
> > post = Post.make(attributes)
> > 3.times { post.comments.make }
> > post
> > end
> > Note here that you can call make on a has_many association. (This
> > isn't yet supported for DataMapper.)
> > ================
>
> > So suppose I write the following:
>
> > def make_complete_quote_object(attributes = {})
> > quote = Quote.make(attributes)
> > 5.times {
> > quote.quotable_operations.make
> > }
> > quote.quotable_quantities.make
>
> > quote
> > end
>
> > Where does that go
>
> I often put these in spec/spec_helper.rb. You may want to refactor
> them out at some point so you can reuse them in your Cucumber steps.
>
> > and do I just use that in lieu of Quote.make? For
> > example:
>
> > new_quote = make_complete_quote_objects(:description => "blah blah
> > blah")
>
> Yes. But... the make method is not the only one you will use. You may
> find yourself creating partial objects look at make_unsaved and plan.
> These will allow you to satisfy certain validation requirements that
> simply can't be gotten from a factory.
>
>
>
> >>> I see
> >>> examples on the Machinist git page that suggest using helper methods
> >>> but that brings me to another road block. Where do I write them? How
> >>> are they called? What types of things should I not be testing at
> >>> that
> >>> level?
>
> >> If memory serves, the Machinist webpage tells you all you need to
> >> know
> >> here.
>
> >>> Now, my own personal itch of a project is still small enough that I
> >>> don't mind ripping entire sections of tests out and rewriting them
> >>> with new frameworks just to learn how. 1) I have the time and 2) I'm
> >>> interested in learning how to do it right more than I am in doing
> >>> it... If that makes sense. The parts of my app work just fine for me
> >>> without tests... but knowing my itch, I'm going to want to add
> >>> complexity and knowing how Ruby and Rails works - I want to add it
> >>> the
> >>> right way so that it's fun for me to do...
>
> >> Great!
>
> >>> Anyway - I'm getting off topic again.
>
> >>> Back in my first post I describe a situation that I was trying to
> >>> test. Could you tell me how I should be approaching that issue
> >>> (which
> >>> may very well be much different than the way I've been approaching
> >>> it). Why is testing from the has_many side so taboo? Is there a
> >>> legitimate way of doing it from the belongs_to side?
>
> >> I think if you just set up your blueprints properly, you'll get
> >> what you
> >> need.
>
> >>> Thank you for your reply and thank you too Marnen.
>
> >>> You have both given me good food for thought, even if I don't know
> >>> how
> >>> to eat it yet.
>
> >>> Hehe. Thanks,
> >>> - FJM
>
> >> You're welcome!
>
> >> Best,
> >> --
> >> Marnen Laibow-Koserhttp://www.marnen.org
> >> [email protected]
> >> --
> >> Posted viahttp://www.ruby-forum.com/.
>
> > Thank you again (and again, I'm sure).
> > - FJM
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Talk" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---