The first part is what you actually write. When you execute it (with a call to 'run' method which isn't shown here), it fails because you don't implement the steps. In an additional file you define "steps" which are helpers for the user story (that's the second part which I call the implementation of a user story).

The description on the official RSpec webpage might be more clear:http://rspec.info/

thanks for the update on RSpec. Maybe I finally found a place where someone can explain to me what I actually gain from using RSpec ? While I do understand what you are doing above technically. I do not get the very basic concept why it's useful.

Because I do not get what is gained by proving this very simple, abstracted "outline" of the functionality you want to implement does indeed work. Of course, If I create an order, an order is created - why do I need to prove that to myself over and over again?

Because, after all, all the "boring" stuff is still left to, Rspec doesn't magically implement the whole thing for me, or does it?

So, is it only to prove basic things like 1 + 1 is indeed 2 (I am exaggerating), but then I do not understand why everybody is so exited about it. Same goes for Testdriven development in Rails - I did read the explanation in Agile Web Dev. with Rails, but what is gained from proving that super-simple abstraction of my functionality work, is beyond me..

>thanks for the update on RSpec. Maybe I >finally found a place where someone can >explain to me what I actually gain from >using RSpec?

What you gain is a specification that is closer to english of what your code _should_ do. RSpec also provides many helpers (like mock_model) that are very helpful when spec'ing your code.

>Of course, If I create an order, an >order is created - why do I need to >prove that to myself over and over >again?

First, you get to know that the code you test involves an order. Second, what happens if even this simple test fails? This can happen, and having a spec failing because of that can be very helpful to avoid looking for the bug in the wrong place.

>I do not get what is gained by proving >this very simple, abstracted "outline" >of the functionality you want to >implement does indeed work.

If you ask the developer (who might yourself :) what the code you are spec'ing was supposed to accomplish, he will not answer:

thank you for the explanations. I think I can understand your reasoning on TDD / BDD and I can imagine scenarios where it could be useful in the very very beginning of thinking of a new application.

It seems to be useful when you do not have the slightest idea what your application has to consist of and what needs to be done.

Say, I want to "make an internet shop", so I have to have products, customers, a shopping cart, and a checkout.

Of course it's important to think about exactly what you need to have and how the parts work together, but what I learned and use on a daily basis is planning these things with pen and paper (making diagrams, etc.)

Now, If I understand right, BDD / TDD is doing the same thing but by code, or am I totally wrong?

For me, going from pen and paper to code seems awkward, as I giving up a lot of flexibility (I can't just draw arrows from a to b, strike out bad ideas, etc. like I could on a huge sheet of paper.

So, actually, it seems a lot more tedious for me to do BDD / TDD than planning on paper (or in a project application if you must), because if I do BDD / TDD, I get the benefit of tests, but these tests only test the very very basic functionality (which needs not to be questioned if planned right on paper). TDD / BDD doesn't save you from all the errors that will be introduced later when you start going from basic to actually implementing.

I am still curious about BDD / TDD as it's still a bit of a mystery to me, but I don't see a place for it between the planning of a software project and the actual, down and dirty implementation.

Maybe I am getting it wrong totally, so I am looking forward to your next blog posting.

It sounds to me like you are used to a more plan driven or predictive development style. Whereas, with rspec, Agile or XP development methodologies are better suited.

There are many advantages to BDD and Agile or XP methodologies. IMO the biggest advantage is the extreme flexibility of the developer developing the application. They should be able to deal with rapidly changing/evolving specifications.

>these tests only test the very very basic functionality

I see this as a positive thing. A decent analogy would be building a foundation for a house of cement blocks. These blocks are really nothing by them selves but added together they form a very sturdy foundation.

>which needs not to be questioned if planned right on paper

It is nearly impossible to plan for every eventuality and if you try you will only waste your time. However, with Agile/XP development methodologies, changes and challenges are welcome. All you have to do is write a "test" and then write just enough code to make it pass.

So in the end you walk away with an application that is more easily extended and documented.