[rspec-devel] [ rspec-Feature Requests-8139 ] & amp; amp; amp; quot; not implemented& amp; amp; amp; quot; message for specs yet to be implemented

noreply at rubyforge.org noreply at rubyforge.org
Fri May 18 21:15:22 EDT 2007


Feature Requests item #8139, was opened at 2007-01-25 11:28
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8139&group_id=797

Category: runner module
Group: None
>Status: Closed
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
>Assigned to: David Chelimsky (dchelimsky)
>Summary: "not implemented" message for specs yet to be implemented

Initial Comment:
If I am defining the behaviour of a class, I might make a list like this:

Money behaviour:
- should parse
- should add
- should subtract
- should multiply
- should handle division by 0
- should handle conversion

I may not know what all of those mean yet, but that is a starting point. I'd like to be able to put that right into specs and have RSpec tell me that I have yet to implement them:

context "Money behaviour" do
  specify "should parse"
  specify "should add"
  specify "should subtract"
  specify "should multiply"
  specify "should handle division by 0"
  specify "should handle conversion"
end

Note that each specify message has no block. Given some command line option, RSpec would collect these during a spec run and add the count to the summary:

=====
Finished in 3.212354 seconds

647 specifications, 0 failures, 25 not yet implemented
=====

Combined with the --format specdoc (or -fs) option, the report would look like this:

=====
Money behaviour:
- should parse
- should add
- should subtract
- should multiply
- should handle division by 0 (NOT IMPLEMENTED
- should handle conversion (NOT IMPLEMENTED)

Finished in 0.212354 seconds

6 specifications, 0 failures, 2 not yet implemented
=====

This would a great aid in monitoring progress during an iteration.


----------------------------------------------------------------------

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-05-19 01:15

Message:
Fixed by applying 10920 (r1973)

----------------------------------------------------------------------

Comment By: Chad Humphries (spicycode)
Date: 2007-05-18 23:59

Message:
Related to patch #10920

----------------------------------------------------------------------

Comment By: Ashley Moran (ashley_moran)
Date: 2007-02-26 14:53

Message:
David,

I like that - it puts all the ideas in one consistent way.  Not implemented would definitely be best for a spec with no block.

Being a TextMate whore, I'm interested to know what the HTML output should be like.  (I live off command-R .)  I think for the individual specs, fail->red, pass->green, needs fixing->orange, not implemented->blue would be helpful.  What I'm not sure about is whether the presence of a "not implemented" or "needs fixing" spec should constitute a failure of the whole spec file.

Possibly something like this would help:

specify "some unimportant features", :state => :needs_fixing, :blocker => false do
  # some failing specs
end

Not sure if this is over-engineering or not - it might be useful for continous integration (we we sadly don't use yet for rails)

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-02-26 12:48

Message:
Sorry - "not implemented" when there is no block or state specified (not "fail").

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-02-26 12:47

Message:
Ashley - between your suggestion of 4 states and Yurii's specify_negatively, I think perhaps something like this might work:

specify "description", :state => state

Where, for now, state could be any of the 4 you suggested. Also, the default state would be "pass" when there is a block (but no state submitted) and "fail" when there is no block (and no state submitted).

WDYT?


----------------------------------------------------------------------

Comment By: Ashley Moran (ashley_moran)
Date: 2007-02-26 12:07

Message:
I'd really like this feature.  I sometimes get into a situation where I need to leave failing specs and work on something else, and the noise is distracting.  I'm tempted to suggest that 4 statuses would be useful: pass, fail, not yet implemented, needs fixing.  I don't know if that would be a good idea, or over-complex.

----------------------------------------------------------------------

Comment By: Ian Dees (undees)
Date: 2007-01-28 22:48

Message:
At work, we have a tool that generates context/specify blocks from our test case descriptions.  Here's what we use:
1) A NonImplementedTest class with an "implemented?" method returning false.
2) A module-level this_test method returning an instance of NonImplementedTest.

So our tool can generate blocks that look like this:

context "A widget" do
  specify "should foobar the frobnitz" do
    # Text from test case:
    # 1) Click the widget button.
    # 2) Make sure the frobnitz is foobar'ed.
    this_test.should_be_implemented
  end
end

That way, we start off red until all the tests are implemented and the software passes them.


----------------------------------------------------------------------

Comment By: Brian Takita (btakita)
Date: 2007-01-28 04:41

Message:
This looks like a good feature. I like the idea of being
able to specify what the software is supposed to do before
implementing it. The specify method without a block
transition s naturally to implementing a full spec.

I remember the conclusion of the other feature request was
to use a TODO statement, which in my opinion in not very
semantic.

----------------------------------------------------------------------

Comment By: Wilson Bilkovich (wilson)
Date: 2007-01-27 00:12

Message:
Hi David,
I was just giving you a hard time.

I remain highly in favor of this feature. I would be happy to help implement it, and/or stuff people who don't like it into trashcans at RailsConf.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-01-26 11:29

Message:
Hi Wilson,

Funny - I forgot about that.

OK - first of all these requests aren't the same. What [#6396] is asking for is a way to stop code from being executed using a keyword disable_specify. What I'm proposing here is different. It's a non-code place-holder right in the spec so I don't have to keep it elsewhere.

Now, reading through the comments on that thread, I see that this idea was already proposed (by me, as it turns out - I'm a bit too young for senility - perhaps a vacation is in order), however even in that proposal I was talking about a special keyword.

This proposal is a little different. It lets me do the same thing but with something that feels more integrated to me - it's the same keyword (specify), and it is noted as something different only by the absence of the block. So to resolve the un-implemented specs I have to add a block and add code, not change keywords.

I guess you could argue that the keyword would make things more obvious when looking at the code, but if we're adding keywords I'd rather have them be more aligned w/ the BDD message - things like "story" and "behaviour".

----------------------------------------------------------------------

Comment By: Wilson Bilkovich (wilson)
Date: 2007-01-26 06:32

Message:
Duplicate? :)
http://rubyforge.org/tracker/index.php?func=detail&aid=6396&group_id=797&atid=3152

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8139&group_id=797


More information about the rspec-devel mailing list