Rspec-getting started

ArticleDirectory

• Preface
• Introduction
• Install
• TDD
• Core
• Introduction to rspec story

Preface

To understand rspec, we need to first understand what is behaviour driven development (BDD), and BDD is an acceptance test driven planning ), domain driven design and agile development model of test driven development (TDD. Rspec provides TDD support for BDD development.

This article follows the TDD idea, but we will use behavior and example to replace test case and test method ).

Introduction

· Textual descriptions of examples and groups (rspec-core)

· Flexible and customizable reporting

· Extensible expectation language (rspec-expectations)

· Built-in mocking/stubbing framework (rspec-MOCKS)

Install

Rails new rspec_tutional-T

Add-T, no test content will be added when the project is created, and then modify gemfile to add the following content:

 
GROUP: Test,: Development do gem 'rspec 'gem 'rspec-rails' (the best version is the same) End
 

Run the following command to create the rspec framework.

Rails g respec: Install

This command is used for railsProgramInstall the rspec framework to replace rspec with test: Unit. This command will create '. rspec 'file, 'spec' directory, and 'spec/spec_helper.rb 'file. Their Respective functions are as follows:

'. Rspec' file: stores the configuration information that rspec needs to load when running the rake spec task.

'Spec 'directory: the storage space of our rspec test cases. For MVC, we can create the models, views, and controllers directories to store test cases at various layers of the model, view, and controller, each test file ends with _ spec.

'Spec/spec_helper.rb 'file: The rspec configuration file that runs the test case. This file must be introduced to every file ending with _ spec, that is, to add: require 'spec _ helper 'at the beginning of the file'Code.

TDD

Describe user do
It "shoshould be in any roles assigned to it" do
User = user. New
User. assign_role ("assigned role ")
User. shoshould be_in_role ("assigned role ")
End
It "shocould not be in any roles not assigned to it" do
User = user. New
User. should_not be_in_role ("unassigned role ")
End
End

Class user
Def in_role? (Role)
Role = @ role
End
Def assign_role (role)
@ Role = role
End
End

Expectations --- built-in matchers

Equivalence

Actual. shocould eq (expected) # passes if actual = expected

Actual. shocould = expected # passes if actual = expected

Actual. shocould eql (expected) # passes if actual. eql? (Expected)

Actual. shocould equal (expected) # passes if actual. Equal? (Expected)

Actual. shoshould === expected # passes if actual === expected


Identity

Actual. shocould be (expected) # passes if actual. Equal? (Expected)

Comparisons

Actual. shocould be> expected

Actual. shocould be> = expected

Actual. shocould be <= expected

Actual. shocould be <expected

Actual. shoshould be_within (DELTA). Of (expected)

Regular Expressions

Actual. shocould = ~ /Expression/

Actual. shocould match (/expression /)

Types/classes

Actual. shocould be_an_instance_of (expected)

Actual. shoshould be_a_kind_of (expected)

Truthiness

Actual. shocould be_true # passes if actual is truthy (not nil or false)

Actual. shocould be_false # passes if actual is falsy (nil or false)

Actual. shoshould be_nil # passes if actual is nil

Expecting errors

Failed CT {...}. To raise_error

Failed CT {...}. To raise_error (errorclass)

Failed CT {...}. To raise_error ("message ")

Failed CT {...}. To raise_error (errorclass, "message ")

Expecting throws

Wrong CT {...}. To throw_symbol

Failed CT {...}. To throw_symbol (: symbol)

Failed CT {...}. To throw_symbol (: symbol, 'value ')

Predicate matchers

Actual. shocould be_xxx # passes if actual. XXX?

Actual. shocould have_xxx (: Arg) # passes if actual. has_xxx? (: Arg)

Ranges (Ruby >=1.9 only)

(1 .. 10). shocould cover (3)

Collection membership

Actual. shocould include (expected)

Examples

[1, 2, 3]. shoshould include (1)

[1, 2, 3]. shoshould include (1, 2)

{: A => 'B'}. shoshould include (: A => 'B ')

"This string". shoshould include ("is str ")

Core

 
The above is a complete template that reflects the rspec organization of test cases. Of course, this is just to illustrate how a _ spec file organizes test cases and basic usage, therefore, I did not write the body of each test case, and the strings in the example are not specific to the specific system and have no practical significance. The following explains the meaning in sequence:
 

 
Require 'spec _ helper ': to load the rspec configuration in the 'spec/spec_helper.rb' file, which is required during running.
 

 
Describe () method:
 

We use the describe () method to define a test case group. The parameters of the describe () method can be the objects to be tested (such as people in the example), or a string, used to describe the group. The content described by the string after the Describe method can correspond to a user story.
 

 
Note that the describe () method can be nested, and the two describe () methods can be used together to further refine a user story, as shown in the describe () method in the above section: "people have enough money pay for house ".
 

 
It () method:
 

 
We use the IT () method to define a specific test case (in rspec, a test case is called an example ). The subsequent string is the parameter of this method, which is used to describe a specific scenario. The IT method body is our definition of the behavior of the system in this scenario.
 

 
The IT () method and describe () method can be used together to completely describe a system behavior. The last test case of the above side is: "people have enough money pay for house shoshould travel ".
 

 
Context () method:
 

 
The context () method works the same as the describe () method. The difference is that describe tends to describe our test object, while the context () method tends to describe user stories using strings.
 

 
Before () and after ():
 

Many test frameworks support these two methods. It must be noted that the parameters of these two methods are marked with the symbol ': Each', indicating that before () is executed first for each test case () code in the method. After the use case is completed, the code in the after () method is executed. If the parameter is ': all', it indicates that before () is executed before all test cases are executed () code in the method. After all the use cases are completed, execute the code in the after () method.
 

 
Rspec also provides the round () method, which does not understand its usage at the moment. It will be added in the subsequent report.
 

 
Help:
 

 
The so-called help method is to extract repeated operations from multiple test cases as a public Method to Improve code reuse. For example, the work_hard () method in the example.
 

 
Sharing behavior:
 

 
A certain behavior of the system is available in many scenarios, so we can define it as a shared behavior. We define the sharing behavior using the pai_examples_for () method and use it_behaves_like () methods share defined system behaviors, such as pai_examples_for "any people" and it_behaves_like "any people" in the example ".
 

 
Pending () method:
 

 
We are sure that the system has an action, but there is no specific definition yet. In this case, we can use the pending () method to set this row as to be determined, the subsequent string parameters are displayed in the generated report.
 

Another use of the pending () method is that when a test case fails, we can use the pending method to set it as a bug to be fixed, the method body contains code that failed to use the sample. For example, the content of the last test case.
 

Introduction to rspec story