rspec users - May 2007 - rspec_on_rails'' spec:doc and dry runs

In rspec_on_rails, the spec:doc task uses --dry-run, which doesn''t
jive well with rspec''s ability to write docs for you.

For example, I use the rspec_expectation_matchers plugin from
spicycode.com (scanned for a name, didn''t find one =), and end up
writing specs like:

    it { @ticket.should validate_presence_of(:name) }

Which results in specdocs such as:

  Ticket
  - NO NAME (Because of --dry-run)
  - NO NAME (Because of --dry-run)
  - NO NAME (Because of --dry-run)

The examples_specdoc task for rspec itself, however, doesn''t use
--dry-run.

Using dry runs presumably speeds things up significantly, but results
in "broken" docs when using one of rspec''s handiest features.
Should
this be considered proper default behavior?

Replacing the task is easy enough, so there''s a good case for dry runs
being the default behavior. I''m just curious.

Kyle

Phil,

I wrote that bit o'' code (the plugin at spicycode).   I
haven''t actually used
the dry-run mode before.  I''ll dig in and see what I can find about the
issue.

Chad

On 5/22/07, Phil O Despotos <philodespotos at gmail.com>
wrote:
>
> In rspec_on_rails, the spec:doc task uses --dry-run, which doesn''t
> jive well with rspec''s ability to write docs for you.
>
> For example, I use the rspec_expectation_matchers plugin from
> spicycode.com (scanned for a name, didn''t find one =), and end up
> writing specs like:
>
>     it { @ticket.should validate_presence_of(:name) }
>
> Which results in specdocs such as:
>
>   Ticket
>   - NO NAME (Because of --dry-run)
>   - NO NAME (Because of --dry-run)
>   - NO NAME (Because of --dry-run)
>
> The examples_specdoc task for rspec itself, however, doesn''t use
> --dry-run.
>
> Using dry runs presumably speeds things up significantly, but results
> in "broken" docs when using one of rspec''s handiest
features. Should
> this be considered proper default behavior?
>
> Replacing the task is easy enough, so there''s a good case for dry
runs
> being the default behavior. I''m just curious.
>
> Kyle
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/rspec-users/attachments/20070522/e99b4da6/attachment.html

On 5/22/07, Phil O Despotos <philodespotos at gmail.com>
wrote:
> In rspec_on_rails, the spec:doc task uses --dry-run, which doesn''t
> jive well with rspec''s ability to write docs for you.
>
> For example, I use the rspec_expectation_matchers plugin from
> spicycode.com (scanned for a name, didn''t find one =), and end up
> writing specs like:
>
>     it { @ticket.should validate_presence_of(:name) }
>
> Which results in specdocs such as:
>
>   Ticket
>   - NO NAME (Because of --dry-run)
>   - NO NAME (Because of --dry-run)
>   - NO NAME (Because of --dry-run)
Self-generated example names were a feature request that got added
much more recently than --dry-run, and the two can''t really work
together. Self-generated names rely on executing the examples and
--dry-run does not actually execute examples. As far as I''m concerned,
--dry-run has almost no value, so I''d actually like to see it
abolished.

2 cents from the peanut gallery.

Cheers,
David
>
> The examples_specdoc task for rspec itself, however, doesn''t use
--dry-run.
>
> Using dry runs presumably speeds things up significantly, but results
> in "broken" docs when using one of rspec''s handiest
features. Should
> this be considered proper default behavior?
>
> Replacing the task is easy enough, so there''s a good case for dry
runs
> being the default behavior. I''m just curious.
>
> Kyle
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

On 5/22/07, Chad Humphries <chad at spicycode.com>
wrote:
> Phil,
>
> I wrote that bit o'' code (the plugin at spicycode).   I
haven''t actually used
> the dry-run mode before.  I''ll dig in and see what I can find
about the
> issue.
The problem is on --dry-run''s end, not yours.

But while I''m here, I just ran into an issue with AssociationMatcher
when using the belong_to matcher. The association uses singular names
(Ticket belongs_to :status), which, when run through :singularize in
the AssociationMatcher constructor, turns status into ''statu''.

I can hack around it by specifying the class_name on both the model
and the spec. I thought I''d be able to just use ''ticket.should
belong_to(:statuses)'', but that isn''t working out.
Don''t know why, but
I haven''t had a chance to really look into it.

Thanks for the awesome plugin.

Kyle
(Fixed my name to actually be my name...)