A few days ago I posted a message asking for help in pointing out
examples of rspec in the wild. I took the input from that thread,
looked through specs from random projects on rubyforge, and pored over
the docs. I decided to make my first project a rewrite of a Protocol
for EventMachine [1] that I had created a few weeks ago.
I want to tap into the hive brain here and make sure I’m doing things
right because I feel kind of nervous.
For example, the original version I wrote used a little fsm (finite
state machine) for reading the header and body from incoming packets
and extracting messages from it. In retrospect this factor probably
made this project a bad choice for my first BDD. The whole “tell,
don’t ask” style doesn’t come into play very much when verifying the
specific states of a fsm.
Anyway, here is a printout of what I have spec’ed so far. I sort of
know which way to go with this design, but even with that
foreknowledge I am surprised how the design is already different. I
am keeping all specs (except one) to a single assertion/check. I am
refactoring my class code when any method exceeds 5 real lines.
I’d like experienced BDD’ers to take a peek here and let me know if
I’m going in the right direction. These specs are for a buffer utility
class used by the EM::Protocol. Any hints or observations would be
appreciated. If you want to see the actual specs or class code, let me
know and I’ll post that in a follow-up.
cremes$ spec buf_spec.rb -f s
Buf (creation)
- should exist
- should default to a header length of 1 like a pascal string
- should take an integer in its initializer specifying header length
- should allow a multi-byte integer in its initializer specifying
header length - should default to the state :read_header given correct input
- should raise an exception given an incorrect argument type in #new
Buf (reading headers, :read_header state)
- should remain in state :read_header when it doesn’t receive the
entire header in one chunk - should transition to the state :read_header_done when it receives
the entire header in one chunk - should transition to the state :read_header_done when it receives
the entire header in 2 chunks - should transition to the state :read_header_done when it receives
the header in multiple chunks
Buf ( interpreting header data, default behavior like pascal string)
- should interpret the header as a packed byte
- should be able to interpret multi-byte headers when the default
header_length is overridden (PENDING: Not Yet Implemented)
Buf (read header and read body, single message)
- should read header and then consume that many bytes as the body
(PENDING: Not Yet Implemented) - should read a whole message and end in the :read_body_done state
(PENDING: Not Yet Implemented) - should transition to :read_header from :read_body_done when given
more data (PENDING: Not Yet Implemented) - should return an array containing a string corresponding to the
input (PENDING: Not Yet Implemented)
Buf (read header and read body, multiple messages)
- should behave like a single message (PENDING: Not Yet Implemented)
- should return an array containing a string element corresponding to
each message from the input (PENDING: Not Yet Implemented)
Pending:
Buf ( interpreting header data, default behavior like pascal string)
should be able to interpret multi-byte headers when the default
header_length is overridden (Not Yet Implemented)
Buf (read header and read body, single message) should read header and
then consume that many bytes as the body (Not Yet Implemented)
Buf (read header and read body, single message) should read a whole
message and end in the :read_body_done state (Not Yet Implemented)
Buf (read header and read body, single message) should transition
to :read_header from :read_body_done when given more data (Not Yet
Implemented)
Buf (read header and read body, single message) should return an array
containing a string corresponding to the input (Not Yet Implemented)
Buf (read header and read body, multiple messages) should behave like
a single message (Not Yet Implemented)
Buf (read header and read body, multiple messages) should return an
array containing a string element corresponding to each message from
the input (Not Yet Implemented)
Finished in 0.011039 seconds
18 examples, 0 failures, 7 pending