Extreme programming, familiarity with Behavior Driven Development and RSpec

Theory

To begin with, let's see what Behavior Driven Development is (hereinafter BDD) and how this technique differs from Test-Driven Development (hereinafter TDD)

Development through testing (English test-driven development) is a programming technique in which unit tests for a program or its fragment are written before the program itself (English test-first development) and, in essence, control its development. It is one of the main practices of extreme programming .

Although the pre-testing approach works for many, it is not for everyone. For each application developer who successfully applies TDD, there are several developers who actively deny this approach. Despite the large number of testing infrastructures, such as TestNG, Selenium and FEST, there are still many reasons not to perform code testing.

Two common reasons for abandoning TDD are “we don’t have enough time to test” and “the code is too complicated and difficult to verify.” Another obstacle for programming with the preliminary writing of tests is the concept of “test is written before the code”. Most consider testing as a tangible action, rather specific than abstract. Experience suggests that it is impossible to verify that which does not yet exist. For some developers who remain within this concept, the idea of ​​pre-testing is just an oxymoron.
')
But what if instead of thinking in terms of writing tests and testing components, start thinking about functionality? Speaking of functionality, I mean how the application should behave, in fact, its specification.

In fact, most of us already think that way. See:

Frank: What is a stack?

Linda: This is a data structure that stores objects in the order “first entered, last exited” or “last entered, first exited”. Usually this structure has an API with methods such as push () and pop (). Sometimes there is a peek () method.

Frank: What does the push () method do?

Linda: The push () method takes an input object, for example, foo, and places it in an internal container, for example, an array. The push () method usually returns nothing.

Frank: What happens if you push two objects to the push () method, for example, foo first and then bar?

Linda: The second bar object should be at the top of the conceptual stack containing at least two objects, so when calling the pop () method, the bar object should be retrieved first, before the first foo object. If the pop () method is called again, the foo object should be returned and the stack should be empty (it is assumed that there was nothing in it before we added these two objects).

Frank: So the pop () method removes the very last element that was added to the stack?

Linda: Yes, the pop () method should remove the top element, and it is assumed that there are elements in the stack to remove them. The peek () method works in the same way, but the object is not deleted. The peek () method should leave the top item on the stack.

Frank: What happens if you call the pop () method when nothing has been added to the stack?

Linda: The pop () method should throw an exception indicating that nothing has been added to the stack yet.

Frank: What happens if you execute the push () command null?

Linda: The stack should throw an exception, since null is not a valid value for the push () method.

Is there anything special about this dialogue, apart from the fact that Frank is not strong in data structures? Nowhere has the word "testing" been used. However, the word "must" slipped regularly and sounded quite natural.

There is nothing new or revolutionary about BDD. This is simply an evolutionary branch of the TDD approach, where the word “test” is replaced by the word “must.” If you put aside the words, many will find the concept of "should" more natural for the development process than the concept of "test". Thinking in terms of functionality (what the code should do) leads to an approach where classes are first written to test specifications, which, in turn, can be a very effective implementation tool.

Practice

RSpec is the BDD framework for Ruby

Installation:

[sudo] gem install rspec

or

git clone git: //github.com/dchelimsky/rspec.git
cd rspec
rake gem
rake install_gem

Let's imagine that your customer is a bank. We illustrate, once again, the dialogue with the customer, in the style of BDD:

You: Please describe how the account should be after its creation?
Customer: The account must have a balance of $ 0.

Here is how we describe this conversation in RSpec:

describe Account, " when first created" do

before do
@account = Account. new
end

it "should have a balance of $0" do
@account.balance.should eql(Money. new (0, :dollars))
end

after do
@account = nil
end

end

* This source code was highlighted with Source Code Highlighter .

If you run this example, RSpec can return a similar description:

Account, when first created
- should have a balance of $ 0

An example of how you can use #before and / or #after blocks in your code:

describe Thing do
before(:all) do
# This is run once and only once, before all of the examples
# and before any before(:each) blocks.
end

before(:each) do
# This is run before each example.
end

before do
# :each is the default, so this is the same as before(:each)
end

it "should do stuff" do
...
end

it "should do more stuff" do
...
end

after(:each) do
# this is before each example
end

after do
# :each is the default, so this is the same as after(:each)
end

after(:all) do
# this is run once and only once after all of the examples
# and after any after(:each) blocks
end

end

* This source code was highlighted with Source Code Highlighter .

Finally

If the article receives positive feedback, a series of articles on this topic will appear.
For starters, below are a few links for in-depth, self-study:

Official documentation (English)
Good step by step manual (English)
Development through testing (rus.)
Introduction to Behavior Driven Development (BDD) (rus.)
BDD Definition
Brief manual on RSpec (English)
TDD Definition (rus.)