From chrisjroos at gmail.com  Mon Jul 24 11:44:27 2006
From: chrisjroos at gmail.com (Chris Roos)
Date: Mon, 24 Jul 2006 16:44:27 +0100
Subject: [Rspec-users] Creating a 'default' mock
Message-ID: <3a5e51050607240844v7614a527i61277d4ccfd226e9@mail.gmail.com>

Am I correct in thinking that it's not currently possible to have a
method that creates a 'standard' mock (i.e. a mock that has defaults
useful in all contexts)?

I've tried with the mock method and also by manually creating new Mock
instances.  I get failures when setting up expectations (undefined
method 'receive' for proc).

Chris

From chrisjroos at gmail.com  Mon Jul 24 12:22:30 2006
From: chrisjroos at gmail.com (Chris Roos)
Date: Mon, 24 Jul 2006 17:22:30 +0100
Subject: [Rspec-users] Mocking causes empty specification blocks
Message-ID: <3a5e51050607240922s37b0cd91h81afb5ab735c74b0@mail.gmail.com>

I've found myself mocking out a published api in my set-up method.
This has led to some contexts having a large set-up and empty
specifications.  As the mocks get auto-verified, the specification
blocks have nothing to do but serve as documentation.  Does this sound
bad?

Chris

From aslak.hellesoy at gmail.com  Mon Jul 24 13:36:07 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Mon, 24 Jul 2006 12:36:07 -0500
Subject: [Rspec-users] Creating a 'default' mock
In-Reply-To: <3a5e51050607240844v7614a527i61277d4ccfd226e9@mail.gmail.com>
References: <3a5e51050607240844v7614a527i61277d4ccfd226e9@mail.gmail.com>
Message-ID: <8d961d900607241036j1b693304w783a2091f63fb8fe@mail.gmail.com>

On 7/24/06, Chris Roos <chrisjroos at gmail.com> wrote:
> Am I correct in thinking that it's not currently possible to have a
> method that creates a 'standard' mock (i.e. a mock that has defaults
> useful in all contexts)?
>

It should be possible to do that. Can you be more specific about what
you mean by defaults?

> I've tried with the mock method and also by manually creating new Mock
> instances.  I get failures when setting up expectations (undefined
> method 'receive' for proc).
>

Please provide some code so we can see what you're trying to do.
Also, which version of RSpec are you using?

> Chris
> _______________________________________________
> Rspec-users mailing list
> Rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

From aslak.hellesoy at gmail.com  Mon Jul 24 13:40:14 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Mon, 24 Jul 2006 12:40:14 -0500
Subject: [Rspec-users] Mocking causes empty specification blocks
In-Reply-To: <3a5e51050607240922s37b0cd91h81afb5ab735c74b0@mail.gmail.com>
References: <3a5e51050607240922s37b0cd91h81afb5ab735c74b0@mail.gmail.com>
Message-ID: <8d961d900607241040h412fd5ia4333cf94f3b9f2e@mail.gmail.com>

On 7/24/06, Chris Roos <chrisjroos at gmail.com> wrote:
> I've found myself mocking out a published api in my set-up method.

What do you mean by mocking a published API. Are you setting up
expectations for all of the API's methods?

> This has led to some contexts having a large set-up and empty
> specifications.  As the mocks get auto-verified, the specification
> blocks have nothing to do but serve as documentation.  Does this sound
> bad?
>

I'm not sure you're using mocks the way they are inteded to be used.

The purpose of a mock is to verify that a certain conversation (i.e.
message passing) takes place between two objects. You should only mock
the methods that you expect to be invoked in a certain situation.
Don't set up expectations for all methods in your mocked API.

Aslak

> Chris
> _______________________________________________
> Rspec-users mailing list
> Rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

From dchelimsky at gmail.com  Mon Jul 24 14:58:38 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Mon, 24 Jul 2006 13:58:38 -0500
Subject: [Rspec-users] Mocking causes empty specification blocks
In-Reply-To: <3a5e51050607240942t1e6b6a8q5595a0cdac3c100d@mail.gmail.com>
References: <3a5e51050607240922s37b0cd91h81afb5ab735c74b0@mail.gmail.com>
	<57c63afe0607240930v30ad1fb6g8948ddb9a51807f6@mail.gmail.com>
	<3a5e51050607240942t1e6b6a8q5595a0cdac3c100d@mail.gmail.com>
Message-ID: <57c63afe0607241158k187a98bcq297adf4b7e3cf915@mail.gmail.com>

On 7/24/06, Chris Roos <chrisjroos at gmail.com> wrote:
> On 7/24/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> > On 7/24/06, Chris Roos <chrisjroos at gmail.com> wrote:
> > > I've found myself mocking out a published api in my set-up method.
> > > This has led to some contexts having a large set-up and empty
> > > specifications.  As the mocks get auto-verified, the specification
> > > blocks have nothing to do but serve as documentation.  Does this sound
> > > bad?
> >
> > What is it that you are specifying? Why are there no statements in the specs?
> >
> I'm specifying the relationship between my object and the mocks.  The
> expectations on the mock object are created in the setup block and
> auto-verified in my empty specification.
>
> I've pasted an example context below.  I'm actually wanting to ensure
> that a validator doesn't get installed.  All the expectations (bar
> :header_row?) are irrelevant in this case; but I don't think I can use
> a null_object mock as I then wouldn't get notified if we try to
> install a validator.
>
> Chris
>
> -- spec --
>
> context "A processed feed validator with one header row but no
> required headers" do
>
>   setup do
>     header_row = mock('header_row')
>     header_row.should_receive(:header_row?).and_return(true)
>     header_row.should_receive(:extend).with(Validatable)
>     header_row.should_receive(:errors)
>     header_row.should_receive(:fields).and_return([[]])
>     io = [header_row]
>     feed_validator = FeedValidator.new(io)
>     feed_validator.process
>   end
>
>   specify "should not install an empty header validator" do
>   end
>
> end

It strikes me that you're mixing setup w/ events. Since your spec is
that "should not install an empty header validator", then put
something in the specify block that indicates when the installation is
happening, and perhaps the specific expectation as well. For example:

context "A processed feed validator with one header row but no
required headers" do

 setup do
   @header_row = mock('header_row')
   @header_row.should_receive(:header_row?).and_return(true)
   @header_row.should_receive(:extend).with(Validatable)
   @header_row.should_receive(:errors)
   @io = [header_row]
   @feed_validator = FeedValidator.new(io)
 end

 specify "should not install an empty header validator" do
   @header_row.should_receive(:fields).and_return([[]])
   @feed_validator.process
 end

end

Also, you can use null_object to tell the mock to not worry about
calls you don't specify. So, for example, you could do this in setup:

   @header_row = mock('header_row', :null_object => true)

and then you don't need this in your setup:

   @header_row.should_receive(:extend).with(Validatable)
   @header_row.should_receive(:errors)

The only things you need in the setup would be the messages that
result in some return value. Then you could have separate specify
blocks for "should supply errors" and "should extend using a
Validitable" (for example).

From chrisjroos at gmail.com  Mon Jul 24 18:23:42 2006
From: chrisjroos at gmail.com (Chris Roos)
Date: Mon, 24 Jul 2006 23:23:42 +0100
Subject: [Rspec-users] Mocking causes empty specification blocks
In-Reply-To: <57c63afe0607241158k187a98bcq297adf4b7e3cf915@mail.gmail.com>
References: <3a5e51050607240922s37b0cd91h81afb5ab735c74b0@mail.gmail.com>
	<57c63afe0607240930v30ad1fb6g8948ddb9a51807f6@mail.gmail.com>
	<3a5e51050607240942t1e6b6a8q5595a0cdac3c100d@mail.gmail.com>
	<57c63afe0607241158k187a98bcq297adf4b7e3cf915@mail.gmail.com>
Message-ID: <3a5e51050607241523k1c99a2ffnd7bd48bf45eaa637@mail.gmail.com>

On 7/24/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> On 7/24/06, Chris Roos <chrisjroos at gmail.com> wrote:
> > On 7/24/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> > > On 7/24/06, Chris Roos <chrisjroos at gmail.com> wrote:
> > > > I've found myself mocking out a published api in my set-up method.
> > > > This has led to some contexts having a large set-up and empty
> > > > specifications.  As the mocks get auto-verified, the specification
> > > > blocks have nothing to do but serve as documentation.  Does this sound
> > > > bad?
> > >
> > > What is it that you are specifying? Why are there no statements in the specs?
> > >
> > I'm specifying the relationship between my object and the mocks.  The
> > expectations on the mock object are created in the setup block and
> > auto-verified in my empty specification.
> >
> > I've pasted an example context below.  I'm actually wanting to ensure
> > that a validator doesn't get installed.  All the expectations (bar
> > :header_row?) are irrelevant in this case; but I don't think I can use
> > a null_object mock as I then wouldn't get notified if we try to
> > install a validator.
> >
> > Chris
> >
> > -- spec --
> >
> > context "A processed feed validator with one header row but no
> > required headers" do
> >
> >   setup do
> >     header_row = mock('header_row')
> >     header_row.should_receive(:header_row?).and_return(true)
> >     header_row.should_receive(:extend).with(Validatable)
> >     header_row.should_receive(:errors)
> >     header_row.should_receive(:fields).and_return([[]])
> >     io = [header_row]
> >     feed_validator = FeedValidator.new(io)
> >     feed_validator.process
> >   end
> >
> >   specify "should not install an empty header validator" do
> >   end
> >
> > end
>
> It strikes me that you're mixing setup w/ events. Since your spec is
> that "should not install an empty header validator", then put
> something in the specify block that indicates when the installation is
> happening, and perhaps the specific expectation as well. For example:
>
> context "A processed feed validator with one header row but no
> required headers" do
>
>  setup do
>    @header_row = mock('header_row')
>    @header_row.should_receive(:header_row?).and_return(true)
>    @header_row.should_receive(:extend).with(Validatable)
>    @header_row.should_receive(:errors)
>    @io = [header_row]
>    @feed_validator = FeedValidator.new(io)
>  end
>
>  specify "should not install an empty header validator" do
>    @header_row.should_receive(:fields).and_return([[]])
>    @feed_validator.process
>  end
>
> end
>
Maybe it would help if I pasted how I would like the code to look..

context "A feed validator with one header row but no required headers" do

 setup do
   @header_row = mock('header_row')
   @header_row.should_receive(:header_row?).and_return(true)
   io = [@header_row]
   @feed_validator = FeedValidator.new(io)
 end

 specify "should not install an empty header validator" do
   @header_row.should_not_receive(:install_validators)
   @feed_validator.process
 end

end

Anything that was in my original example that is not above was there
because otherwise my mock will complain of unexpected methods being
called.  I don't think I'm able to use the :null_object option as I'm
relying on the fact that my mock complains if the install_validators
message is sent.  Note the made up 'should_not_reveive' method above.
Maybe if I had something like this then I could indeed use the
null_object option?

As for having the feed_validator.process line in the setup, that was
kinda taken from the rSpec tutorial (re 'should not be empty after
push').  I was thinking along the lines of this object already being
processed.

Thanks for the help guys.

Chris

> Also, you can use null_object to tell the mock to not worry about
> calls you don't specify. So, for example, you could do this in setup:
>
>    @header_row = mock('header_row', :null_object => true)
>
> and then you don't need this in your setup:
>
>    @header_row.should_receive(:extend).with(Validatable)
>    @header_row.should_receive(:errors)
>
> The only things you need in the setup would be the messages that
> result in some return value. Then you could have separate specify
> blocks for "should supply errors" and "should extend using a
> Validitable" (for example).
> _______________________________________________
> Rspec-users mailing list
> Rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

From chrisjroos at gmail.com  Tue Jul 25 03:03:19 2006
From: chrisjroos at gmail.com (Chris Roos)
Date: Tue, 25 Jul 2006 08:03:19 +0100
Subject: [Rspec-users] Mocking causes empty specification blocks
In-Reply-To: <57c63afe0607241734m27d06df0wd4e9f675f600221c@mail.gmail.com>
References: <3a5e51050607240922s37b0cd91h81afb5ab735c74b0@mail.gmail.com>
	<57c63afe0607240930v30ad1fb6g8948ddb9a51807f6@mail.gmail.com>
	<3a5e51050607240942t1e6b6a8q5595a0cdac3c100d@mail.gmail.com>
	<57c63afe0607241158k187a98bcq297adf4b7e3cf915@mail.gmail.com>
	<3a5e51050607241523k1c99a2ffnd7bd48bf45eaa637@mail.gmail.com>
	<57c63afe0607241734m27d06df0wd4e9f675f600221c@mail.gmail.com>
Message-ID: <3a5e51050607250003m4eda7225radb242a18af39137@mail.gmail.com>

On 7/25/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> On 7/24/06, Chris Roos <chrisjroos at gmail.com> wrote:
> > Maybe it would help if I pasted how I would like the code to look..
> >
> > context "A feed validator with one header row but no required headers" do
> >
> >  setup do
> >    @header_row = mock('header_row')
> >    @header_row.should_receive(:header_row?).and_return(true)
> >    io = [@header_row]
> >    @feed_validator = FeedValidator.new(io)
> >  end
> >
> >  specify "should not install an empty header validator" do
> >    @header_row.should_not_receive(:install_validators)
> >    @feed_validator.process
> >  end
> >
> > end
> >
> > Anything that was in my original example that is not above was there
> > because otherwise my mock will complain of unexpected methods being
> > called.  I don't think I'm able to use the :null_object option as I'm
> > relying on the fact that my mock complains if the install_validators
> > message is sent.  Note the made up 'should_not_reveive' method above.
> > Maybe if I had something like this then I could indeed use the
> > null_object option?
> >
> > As for having the feed_validator.process line in the setup, that was
> > kinda taken from the rSpec tutorial (re 'should not be empty after
> > push').  I was thinking along the lines of this object already being
> > processed.
>
> null_object only ignores things that you do not specify. If you
> specify that something should not be received, it should complain if
> it receives it. If it does not complain, raise a bug! That's how it
> should work.
>
> Cheers,
> David
>
Ahh, I couldn't previously find anyway of specifying that something
should not be called (I was trying should_not).  I've just realised
that I need to do should_receive(:foo).never.

Not sure if it's possible but I'd guess the should_not_receive may be
more intuitive?

With this info, I'll tidy my specs and see how they now look.

Thanks for all the help.

Chris

From chrisjroos at gmail.com  Tue Jul 25 07:31:52 2006
From: chrisjroos at gmail.com (Chris Roos)
Date: Tue, 25 Jul 2006 12:31:52 +0100
Subject: [Rspec-users] Creating a 'default' mock
In-Reply-To: <8d961d900607241036j1b693304w783a2091f63fb8fe@mail.gmail.com>
References: <3a5e51050607240844v7614a527i61277d4ccfd226e9@mail.gmail.com>
	<8d961d900607241036j1b693304w783a2091f63fb8fe@mail.gmail.com>
Message-ID: <3a5e51050607250431q3884a3afwe06a9036ea669c7e@mail.gmail.com>

On 7/24/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> On 7/24/06, Chris Roos <chrisjroos at gmail.com> wrote:
> > Am I correct in thinking that it's not currently possible to have a
> > method that creates a 'standard' mock (i.e. a mock that has defaults
> > useful in all contexts)?
> >
>
> It should be possible to do that. Can you be more specific about what
> you mean by defaults?
>
Although I don't currently need this anymore...  I was wanting a way
to create a mock object that responded in certain ways to some stock
messages.  I then wanted to be able to use this mock in each of my
different contexts by customising it with expectations.

> > I've tried with the mock method and also by manually creating new Mock
> > instances.  I get failures when setting up expectations (undefined
> > method 'receive' for proc).
> >
>
> Please provide some code so we can see what you're trying to do.
> Also, which version of RSpec are you using?
>
Version 0.5.15.  I was doing something like...

def mock_row
 row = mock('row')
 row.expects(:foo).returns('bar')
 row
end

... and then trying to re-use it in my context set-ups.  This is where I
got the error stated in the original email.

The reason that this is no longer required is because I realised the
way to ensure that message _are not_ received (receive(:foo).never).
This allows me to set my mocks as null_objects and remove lots of the
duplication that I was trying to solve with this 'default mock'

Cheers,

Chris

> > Chris
> > _______________________________________________
> > Rspec-users mailing list
> > Rspec-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-users
> >
> _______________________________________________
> Rspec-users mailing list
> Rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

From chrisjroos at gmail.com  Tue Jul 25 07:39:28 2006
From: chrisjroos at gmail.com (Chris Roos)
Date: Tue, 25 Jul 2006 12:39:28 +0100
Subject: [Rspec-users] Some specs
Message-ID: <3a5e51050607250439w7609ca93p24d3101e35283da6@mail.gmail.com>

Hi,

I'd really appreciate someone looking at some specifications I have.
The context in each case is realised in the setup block (I'm assuming
this is standard practice?).  The specifications should be
self-explanatory.

I'm wondering if anyone can see anything obviously bad/wrong with what
I have?  I'm intentionally not stating anything else as in theory the
specs should speak for themselves.

Thanks in advance,

Chris

---- specifications ----

A validatable object with no validators
- should be valid
- should have no error messages

A validatable object with an always valid validator
- should be valid
- should have no error message

A validatable object with an always invalid validator
- should be invalid
- should have the standard error message

A validatable object with an always invalid validator and an
overridden standard error message
- should use the overridden standard error message

A validatable object with an always invalid validator that has a
custom error message
- should have the custom error message

A validatable object with one always valid validator and one always
invalid validator
- should be invalid
- should have the standard error message

A validatable object with two always invalid validators, one of which
has a custom error message
- should be invalid
- should have standard and custom error message

From dchelimsky at gmail.com  Tue Jul 25 10:49:18 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Tue, 25 Jul 2006 09:49:18 -0500
Subject: [Rspec-users] Mocking causes empty specification blocks
In-Reply-To: <3a5e51050607250003m4eda7225radb242a18af39137@mail.gmail.com>
References: <3a5e51050607240922s37b0cd91h81afb5ab735c74b0@mail.gmail.com>
	<57c63afe0607240930v30ad1fb6g8948ddb9a51807f6@mail.gmail.com>
	<3a5e51050607240942t1e6b6a8q5595a0cdac3c100d@mail.gmail.com>
	<57c63afe0607241158k187a98bcq297adf4b7e3cf915@mail.gmail.com>
	<3a5e51050607241523k1c99a2ffnd7bd48bf45eaa637@mail.gmail.com>
	<57c63afe0607241734m27d06df0wd4e9f675f600221c@mail.gmail.com>
	<3a5e51050607250003m4eda7225radb242a18af39137@mail.gmail.com>
Message-ID: <57c63afe0607250749g4b1266a1k421e9cebdbc00717@mail.gmail.com>

On 7/25/06, Chris Roos <chrisjroos at gmail.com> wrote:

> Ahh, I couldn't previously find anyway of specifying that something
> should not be called (I was trying should_not).  I've just realised
> that I need to do should_receive(:foo).never.
>
> Not sure if it's possible but I'd guess the should_not_receive may be
> more intuitive?

I think you're right. Can you raise this as an issue at rubyforge?

From chrisjroos at gmail.com  Tue Jul 25 13:23:08 2006
From: chrisjroos at gmail.com (Chris Roos)
Date: Tue, 25 Jul 2006 18:23:08 +0100
Subject: [Rspec-users] Mocking causes empty specification blocks
In-Reply-To: <57c63afe0607250749g4b1266a1k421e9cebdbc00717@mail.gmail.com>
References: <3a5e51050607240922s37b0cd91h81afb5ab735c74b0@mail.gmail.com>
	<57c63afe0607240930v30ad1fb6g8948ddb9a51807f6@mail.gmail.com>
	<3a5e51050607240942t1e6b6a8q5595a0cdac3c100d@mail.gmail.com>
	<57c63afe0607241158k187a98bcq297adf4b7e3cf915@mail.gmail.com>
	<3a5e51050607241523k1c99a2ffnd7bd48bf45eaa637@mail.gmail.com>
	<57c63afe0607241734m27d06df0wd4e9f675f600221c@mail.gmail.com>
	<3a5e51050607250003m4eda7225radb242a18af39137@mail.gmail.com>
	<57c63afe0607250749g4b1266a1k421e9cebdbc00717@mail.gmail.com>
Message-ID: <3a5e51050607251023o349593b3ub75c821152b2a3e1@mail.gmail.com>

On 7/25/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> On 7/25/06, Chris Roos <chrisjroos at gmail.com> wrote:
>
> > Ahh, I couldn't previously find anyway of specifying that something
> > should not be called (I was trying should_not).  I've just realised
> > that I need to do should_receive(:foo).never.
> >
> > Not sure if it's possible but I'd guess the should_not_receive may be
> > more intuitive?
>
> I think you're right. Can you raise this as an issue at rubyforge?

Added as a feature request.

Chris

From dominique.plante at gmail.com  Sat Jul 29 04:46:40 2006
From: dominique.plante at gmail.com (Dominique Plante)
Date: Sat, 29 Jul 2006 01:46:40 -0700
Subject: [Rspec-users] deflexion exercise?
Message-ID: <a4150eba0607290146y4dc81c67y96ed6fe956e8bed@mail.gmail.com>

I read the Ed Gibbs blog posting on BDD, and there was a reference to
implementing the game Deflexions as a way of learning about
expectations...

I'd like to do this exercise, can you provide me with the details
(starting points, objectives, etc...)

Thanks!
Dominique

-------------------------------------------------------------
dom.website = http://www.binaryshift.com

From dominique.plante at gmail.com  Sat Jul 29 04:51:48 2006
From: dominique.plante at gmail.com (Dominique Plante)
Date: Sat, 29 Jul 2006 01:51:48 -0700
Subject: [Rspec-users] comments on my first context
Message-ID: <a4150eba0607290151rcaee27dmd42dc82fe8ba4ade@mail.gmail.com>

I have been curious about rSpec for a while, so I thought I'd give it a try...

I started reading Ron Jeffries' articles on Sudoku
(http://www.xprogramming.com/xpmag/OkSudoku.htm), and noticed he was
doing TDD, I thought, this would be fun to do with BDD...

Can you comment on the following? (note that I added a method in the
Game class called cells which return @cells) to make the first spec
work)

Thanks!
Dominique

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

# Inspired by:
# http://www.xprogramming.com/xpmag/OkSudoku.htm
# http://rspec.rubyforge.org/

require 'Game'

context "An Empty Board" do
  setup do
    @game = Game.test_game
  end

  specify "should have 81 cells" do
    @game.should.have(81).cells
  end

  specify "should have 0..80 in the cells" do
    (0..80).each do | i |
      @game.cell(i).should.equal i
    end
  end

  specify "check values in row 3" do
    @game.row(3).should.equal [27, 28, 29, 30, 31, 32, 33, 34, 35]
  end

  specify "check values in row 8" do
    @game.row(8).should.equal [72, 73, 74, 75, 76, 77, 78, 79, 80]
  end

  specify "check values in column 3" do
    @game.column(3).should.equal [3, 12, 21, 30, 39, 48, 57, 66, 75]
  end

  specify "check values in square 4 (middle square, counting from 0)" do
    @game.square(4).should.equal [30, 31, 32, 39, 40, 41, 48, 49, 50]
  end

  specify "check values in square 8 (last square, counting from 0)" do
    @game.square(8).should.equal [60, 61, 62, 69, 70, 71, 78, 79, 80]
  end

end
-------------------------------------------------------------
dom.website = http://www.binaryshift.com

From dchelimsky at gmail.com  Sat Jul 29 08:12:13 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Sat, 29 Jul 2006 07:12:13 -0500
Subject: [Rspec-users] Fwd:  comments on my first context
In-Reply-To: <57c63afe0607290511r5d4ab38q9e2213021e02f694@mail.gmail.com>
References: <a4150eba0607290151rcaee27dmd42dc82fe8ba4ade@mail.gmail.com>
	<57c63afe0607290511r5d4ab38q9e2213021e02f694@mail.gmail.com>
Message-ID: <57c63afe0607290512u7881824fgc0c244018f65581d@mail.gmail.com>

This was intended for the whole group.

---------- Forwarded message ----------
From: David Chelimsky <dchelimsky at gmail.com>
Date: Jul 29, 2006 7:11 AM
Subject: Re: [Rspec-users] comments on my first context
To: Dominique Plante <dominique.plante at gmail.com>


On 7/29/06, Dominique Plante <dominique.plante at gmail.com> wrote:
> I have been curious about rSpec for a while, so I thought I'd give it a try...
>
> I started reading Ron Jeffries' articles on Sudoku
> (http://www.xprogramming.com/xpmag/OkSudoku.htm), and noticed he was
> doing TDD, I thought, this would be fun to do with BDD...
>
> Can you comment on the following? (note that I added a method in the
> Game class called cells which return @cells) to make the first spec
> work)

Interesting example. BDD is about behaviour, and you've picked an
example (sudoku) that seems to be inherently about state ("An Empty
Board should have 81 squares"). The behavioural aspects (interactions)
won't show up for a while on the path that you're on. But that's OK
for now.

The expectations you've written are all fine (i.e. the code in the
specs), but the names are a bit confusing. Right now, the output would
be this:

An Empty Board
-should have 81 cells
-should have 0..80 in the cells
-check values in row 3
-check values in row 8
-check values in column 3
-check values in square 4 (middle square, counting from 0)
-check values in square 8 (last square, counting from 0)

Think about how that reads and what it conveys. There are a few points
of confusion here. The second spec "should have 0..80 in the cells"
doesn't make sense in An Empty Board. It might make sense in A Sample
Board, or something like that. Also, "An Empty Board check values in
row 3" reads a bit funny. You get the idea.

I'd recommend that you play around w/ the names so that the output
makes more sense. Part of the idea is to get your head out of the code
and think about the communication aspects (i.e. how you would use this
output to express the intent of the system), and that doesn't always
become apparent until you look at the output as a whole.

Feel free to post back when you've made some changes.

Have fun!

David

>
> Thanks!
> Dominique
>
> ----------------------------------------------------------
>
> # Inspired by:
> # http://www.xprogramming.com/xpmag/OkSudoku.htm
> # http://rspec.rubyforge.org/
>
> require 'Game'
>
> context "An Empty Board" do
>   setup do
>     @game = Game.test_game
>   end
>
>   specify "should have 81 cells" do
>     @game.should.have(81).cells
>   end
>
>   specify "should have 0..80 in the cells" do
>     (0..80).each do | i |
>       @game.cell(i).should.equal i
>     end
>   end
>
>   specify "check values in row 3" do
>     @game.row(3).should.equal [27, 28, 29, 30, 31, 32, 33, 34, 35]
>   end
>
>   specify "check values in row 8" do
>     @game.row(8).should.equal [72, 73, 74, 75, 76, 77, 78, 79, 80]
>   end
>
>   specify "check values in column 3" do
>     @game.column(3).should.equal [3, 12, 21, 30, 39, 48, 57, 66, 75]
>   end
>
>   specify "check values in square 4 (middle square, counting from 0)" do
>     @game.square(4).should.equal [30, 31, 32, 39, 40, 41, 48, 49, 50]
>   end
>
>   specify "check values in square 8 (last square, counting from 0)" do
>     @game.square(8).should.equal [60, 61, 62, 69, 70, 71, 78, 79, 80]
>   end
>
> end
> -------------------------------------------------------------
> dom.website = http://www.binaryshift.com
> _______________________________________________
> Rspec-users mailing list
> Rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

From demmer12 at fastmail.us  Sat Jul 29 13:06:47 2006
From: demmer12 at fastmail.us (Craig Demyanovich)
Date: Sat, 29 Jul 2006 13:06:47 -0400
Subject: [Rspec-users] benefitting from specdoc after each run
Message-ID: <23F5AD83-09BE-4E0D-B7CC-392CDE424052@fastmail.us>

Greetings,

In the thread on another user's first context, David offered his  
advice based on how the output read in specdoc format. My thinking to- 
date about the specdoc format is that it was this great thing to have  
when I was done with my software. I now realize that it can be so  
much more than that if read after each run of the specs! I foresee  
that reading it after each run may allow me to notice things about my  
design that I might not have noticed by reading only the code; or, it  
might help me notice them sooner. Thanks for the spark, David!

Craig

P.S. David, I see that you now spell "behaviour" like Dave does. ;-)

From aslak.hellesoy at gmail.com  Sat Jul 29 13:16:52 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Sat, 29 Jul 2006 12:16:52 -0500
Subject: [Rspec-users] deflexion exercise?
In-Reply-To: <a4150eba0607290146y4dc81c67y96ed6fe956e8bed@mail.gmail.com>
References: <a4150eba0607290146y4dc81c67y96ed6fe956e8bed@mail.gmail.com>
Message-ID: <8d961d900607291016t6d94b90ck1631cb5673760fce@mail.gmail.com>

On 7/29/06, Dominique Plante <dominique.plante at gmail.com> wrote:
> I read the Ed Gibbs blog posting on BDD, and there was a reference to
> implementing the game Deflexions as a way of learning about
> expectations...
>

I googled, but couldn't find any Ed Gibbs blog posting on BDD or Deflexions.

Where is it?

Aslak

> I'd like to do this exercise, can you provide me with the details
> (starting points, objectives, etc...)
>
> Thanks!
> Dominique
>
> -------------------------------------------------------------
> dom.website = http://www.binaryshift.com
> _______________________________________________
> Rspec-users mailing list
> Rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

From dominique.plante at gmail.com  Sat Jul 29 15:07:18 2006
From: dominique.plante at gmail.com (Dominique Plante)
Date: Sat, 29 Jul 2006 12:07:18 -0700
Subject: [Rspec-users] deflexion exercise?
In-Reply-To: <8d961d900607291016t6d94b90ck1631cb5673760fce@mail.gmail.com>
References: <a4150eba0607290146y4dc81c67y96ed6fe956e8bed@mail.gmail.com>
	<8d961d900607291016t6d94b90ck1631cb5673760fce@mail.gmail.com>
Message-ID: <a4150eba0607291207p35e69796x32b3f1a382310016@mail.gmail.com>

I don't know where it is - that's what I was asking!  I'm not sure if
the idea was to start completely from scratch, or if the exercise
already included some code already - also, I was curious to see if
there were certain scenarios that we could start modelling (i.e. you
should be able to detect that when the pieces are here, and facing
this way, it should result in a win)

Thanks!
Dominique

On 7/29/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> On 7/29/06, Dominique Plante <dominique.plante at gmail.com> wrote:
> > I read the Ed Gibbs blog posting on BDD, and there was a reference to
> > implementing the game Deflexions as a way of learning about
> > expectations...
> >
>
> I googled, but couldn't find any Ed Gibbs blog posting on BDD or Deflexions.
>
> Where is it?
>
> Aslak
>
> > I'd like to do this exercise, can you provide me with the details
> > (starting points, objectives, etc...)
> >
> > Thanks!
> > Dominique
> >
> > -------------------------------------------------------------
> > dom.website = http://www.binaryshift.com
> > _______________________________________________
> > Rspec-users mailing list
> > Rspec-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-users
> >
>


-- 
-------------------------------------------------------------
dom.website = http://www.binaryshift.com

From dominique.plante at gmail.com  Sat Jul 29 15:11:54 2006
From: dominique.plante at gmail.com (Dominique Plante)
Date: Sat, 29 Jul 2006 12:11:54 -0700
Subject: [Rspec-users] comments on my first context
In-Reply-To: <57c63afe0607290511r5d4ab38q9e2213021e02f694@mail.gmail.com>
References: <a4150eba0607290151rcaee27dmd42dc82fe8ba4ade@mail.gmail.com>
	<57c63afe0607290511r5d4ab38q9e2213021e02f694@mail.gmail.com>
Message-ID: <a4150eba0607291211u6b2dc5e0t858e27235c4515de@mail.gmail.com>

Dear David:

Thanks for the feedback!  Your feedback makes sense - I will play
around with the names, and think about the behavior as I go a little
bit further along...

I think what's interesting that you are suggesting is that there are
assertions that feel natural in TDD that you wouldn't want to mimic in
BDD...

Thanks!
Dominique

On 7/29/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> On 7/29/06, Dominique Plante <dominique.plante at gmail.com> wrote:
> > I have been curious about rSpec for a while, so I thought I'd give it a try...
> >
> > I started reading Ron Jeffries' articles on Sudoku
> > (http://www.xprogramming.com/xpmag/OkSudoku.htm), and noticed he was
> > doing TDD, I thought, this would be fun to do with BDD...
> >
> > Can you comment on the following? (note that I added a method in the
> > Game class called cells which return @cells) to make the first spec
> > work)
>
> Interesting example. BDD is about behaviour, and you've picked an
> example (sudoku) that seems to be inherently about state ("An Empty
> Board should have 81 squares"). The behavioural aspects (interactions)
> won't show up for a while on the path that you're on. But that's OK
> for now.
>
> The expectations you've written are all fine (i.e. the code in the
> specs), but the names are a bit confusing. Right now, the output would
> be this:
>
> An Empty Board
> -should have 81 cells
> -should have 0..80 in the cells
> -check values in row 3
> -check values in row 8
> -check values in column 3
> -check values in square 4 (middle square, counting from 0)
> -check values in square 8 (last square, counting from 0)
>
> Think about how that reads and what it conveys. There are a few points
> of confusion here. The second spec "should have 0..80 in the cells"
> doesn't make sense in An Empty Board. It might make sense in A Sample
> Board, or something like that. Also, "An Empty Board check values in
> row 3" reads a bit funny. You get the idea.
>
> I'd recommend that you play around w/ the names so that the output
> makes more sense. Part of the idea is to get your head out of the code
> and think about the communication aspects (i.e. how you would use this
> output to express the intent of the system), and that doesn't always
> become apparent until you look at the output as a whole.
>
> Feel free to post back when you've made some changes.
>
> Have fun!
>
> David
>
> >
> > Thanks!
> > Dominique
> >
> > ----------------------------------------------------------
> >
> > # Inspired by:
> > # http://www.xprogramming.com/xpmag/OkSudoku.htm
> > # http://rspec.rubyforge.org/
> >
> > require 'Game'
> >
> > context "An Empty Board" do
> >   setup do
> >     @game = Game.test_game
> >   end
> >
> >   specify "should have 81 cells" do
> >     @game.should.have(81).cells
> >   end
> >
> >   specify "should have 0..80 in the cells" do
> >     (0..80).each do | i |
> >       @game.cell(i).should.equal i
> >     end
> >   end
> >
> >   specify "check values in row 3" do
> >     @game.row(3).should.equal [27, 28, 29, 30, 31, 32, 33, 34, 35]
> >   end
> >
> >   specify "check values in row 8" do
> >     @game.row(8).should.equal [72, 73, 74, 75, 76, 77, 78, 79, 80]
> >   end
> >
> >   specify "check values in column 3" do
> >     @game.column(3).should.equal [3, 12, 21, 30, 39, 48, 57, 66, 75]
> >   end
> >
> >   specify "check values in square 4 (middle square, counting from 0)" do
> >     @game.square(4).should.equal [30, 31, 32, 39, 40, 41, 48, 49, 50]
> >   end
> >
> >   specify "check values in square 8 (last square, counting from 0)" do
> >     @game.square(8).should.equal [60, 61, 62, 69, 70, 71, 78, 79, 80]
> >   end
> >
> > end
> > -------------------------------------------------------------
> > dom.website = http://www.binaryshift.com
> > _______________________________________________
> > Rspec-users mailing list
> > Rspec-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-users
> >
>


-- 
-------------------------------------------------------------
dom.website = http://www.binaryshift.com

From chrisjroos at gmail.com  Mon Jul 31 07:40:39 2006
From: chrisjroos at gmail.com (Chris Roos)
Date: Mon, 31 Jul 2006 12:40:39 +0100
Subject: [Rspec-users] Textmate command to display specifications
Message-ID: <3a5e51050607310440p342ffdddodf2891963c253d10@mail.gmail.com>

I've added a command that displays the html formatted output of some
specifications.  It's as simple as..

#!/bin/sh

/usr/bin/env spec $TM_FILEPATH -fhtml

I'm wondering if anyone has anything more sophisticated (although to
be fair, this does the job for now)?  I've seen some posts about a
rspec on rails textmate command but haven't taken a look at it in
detail.

Chris

From aslak.hellesoy at gmail.com  Mon Jul 31 20:27:10 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Mon, 31 Jul 2006 19:27:10 -0500
Subject: [Rspec-users] Textmate command to display specifications
In-Reply-To: <3a5e51050607310440p342ffdddodf2891963c253d10@mail.gmail.com>
References: <3a5e51050607310440p342ffdddodf2891963c253d10@mail.gmail.com>
Message-ID: <8d961d900607311727m5337e1dwf8690922d2551395@mail.gmail.com>

If you have some code to share, please upload it to the patches
tracker on rubyforge.

We'd be happy to include it in our releases as separate bundles.

Aslak

On 7/31/06, Chris Roos <chrisjroos at gmail.com> wrote:
> I've added a command that displays the html formatted output of some
> specifications.  It's as simple as..
>
> #!/bin/sh
>
> /usr/bin/env spec $TM_FILEPATH -fhtml
>
> I'm wondering if anyone has anything more sophisticated (although to
> be fair, this does the job for now)?  I've seen some posts about a
> rspec on rails textmate command but haven't taken a look at it in
> detail.
>
> Chris
> _______________________________________________
> Rspec-users mailing list
> Rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

From aslak.hellesoy at gmail.com  Mon Jul 31 23:56:45 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Mon, 31 Jul 2006 22:56:45 -0500
Subject: [Rspec-users] [ANN] 0.5.16 released
Message-ID: <8d961d900607312056i3213fea4pece806938decc345@mail.gmail.com>

The biggest change is simplified rails support in a new wrapping.
See release notes and website for details:

http://rubyforge.org/frs/shownotes.php?release_id=6247
http://rspec.rubyforge.org/tools/rails.html

Aslak