I don't get rspec

Ruby
41

On 1/24/07, Luke I. [email protected] wrote:

I know I’m not the person that this was targeted at, but I would absolutely
love to see nested contexts included in rspec… I was just wishing I could
do that yesterday.

Google this:

pipermail rspec nested contexts

and you’ll see what’s been said about it before. Feel free to
resurrect the discussion on the rspec-devel or rspec-users list if you
have some new insights to add to the discussion.

Cheers,
David

42

“David C.” [email protected] writes:

user = User.new
setup do
kind of interesting.
I’m not sure how I could implement that (and I wont ;-)). But maybe
includable setups would be useful.

module UserSetup
setup do # ???
@user = User.new
end
end

context “Users” do
context “with a valid email address” do
include UserSetup
setup { @user.email … }
end
context “with a valid email address” do
include UserSetup
setup { @user.email … }
end
end

That shouldn’t be too hard to do…

43

On 1/24/07, Christian N. [email protected] wrote:

@user = User.new

end
end

It’s actually pretty easy if you don’t mind using the Module#included
hook.

module UserSetup
def self.included(context)
context.setup do
@user = User.new
end
end
end

But I’m sure you would have figured that out eventually… :slight_smile:

context “Users” do

context “with a valid email address” do
include UserSetup
setup { @user.email … }
end
context “with a valid email address” do
include UserSetup
setup { @user.email … }
end
end

Cheers,
/Nick

44

M. Edward (Ed) Borasky wrote:

I do have a bone to pick with the tutorial (or maybe I don’t understand
TDD/BDD yet). In the stack example, I cringe with horror when I see them
setting a method that just returns “true” simply to get a test to pass.
That grates on me, because I know I’m actually going to have to write
the real code eventually. It seems like a waste of time to do the
nitty-gritty “add a test to the spec/add a trivial fix to the code” cycle.

The idea behind doing small steps is that you know exactly what went
wrong
when you run the tests. If you roll several steps into one
test/development
cycle then you have many possibilities to investigate what went wrong if
they fail.

Sometimes, it is easier to skip the most trivial steps though!

45

they fail.

Sometimes, it is easier to skip the most trivial steps though!

Also keep in mind that is just a tutorial example. The goal is just to
communicate the process - spec first, make the spec pass, next step.
It’s all about a single point of failure, and a clear mapping between
specs and functionality.

–
Giles B.

Blog: http://gilesbowkett.blogspot.com
Portfolio: http://www.gilesgoatboy.org

46

“Nick S.” [email protected] writes:

setup do # ???
@user = User.new
end
end
end

But I’m sure you would have figured that out eventually… :slight_smile:

Nifty, thanks!

47

On 6/25/07, Giles B. [email protected] wrote:

Also keep in mind that is just a tutorial example. The goal is just to
communicate the process - spec first, make the spec pass, next step.
It’s all about a single point of failure, and a clear mapping between
specs and functionality.

Actually I believe that the pure process of
test-driven/behavior-driven development is:

  1. Write the test/spec
  2. Ensure that it FAILS
  3. Write the code to make it pass
  4. Goto step 1

Step 2 is to debug the spec.

–
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

48

On 6/27/07, Rick DeNatale [email protected] wrote:

  1. Write the test/spec
  2. Ensure that it FAILS
  3. Write the code to make it pass
  4. Goto step 1

Step 2 is to debug the spec.

The reason that we want to see the test fail is so that we can
confident that when it passes that it’s passing because of the code we
wrote in step 3. Otherwise, we could write code that the test doesn’t
interact with in any way resulting in a useless test and dead code.

Is that what you mean by “debug the spec?” If not, can you please
explain?

Thx,
David

49

On 6/27/07, David C. [email protected] wrote:

interact with in any way resulting in a useless test and dead code.

Is that what you mean by “debug the spec?” If not, can you please explain?

Better late than never. Yes

–
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

50

On 7/18/07, Rick DeNatale [email protected] wrote:

test-driven/behavior-driven development is:
wrote in step 3. Otherwise, we could write code that the test doesn’t
interact with in any way resulting in a useless test and dead code.

Is that what you mean by “debug the spec?” If not, can you please explain?

Better late than never. Yes

:slight_smile:

Thanks