- RSpec Essentials
- Mani Tadayon
- 398字
- 2021-07-09 19:33:38
Structure of a spec file
Let's look again at the AddressValidator
module we introduced in Chapter 1, Exploring Testability from Unit Tests to Behavior-Driven Development, so we can understand its structure better. We'll also use some basic RSpec features to improve the tests. Let's look at the spec code:
require 'rspec' require_relative 'address_validator' describe AddressValidator do it "returns false for incomplete address" do address = { street: "123 Any Street", city: "Anytown" } expect( AddressValidator.valid?(address) ).to eq(false) end it "missing_parts returns an array of missing required parts" do address = { street: "123 Any Street", city: "Anytown" } expect( AddressValidator.missing_parts(address) ).to eq([:region, :postal_code, :country]) end end
We defined a local variable address
in each example. This is fine for simple, one-off values. We could get the same functionality shared across multiple tests with a local function defined within the scope:
describe AddressValidator do def address { street: "123 Any Street", city: "Anytown" } end it "returns false for incomplete address" do expect(AddressValidator.valid?(address)).to eq(false) end it "missing_parts returns an array of missing required parts" do expect( AddressValidator.missing_parts(address) ).to eq([:region, :postal_code, :country]) end end
If the same value is used in more than one test, an instance variable in a before
block can be used:
describe AddressValidator do # this block replaces the 'address' method before do @address = { street: "123 Any Street", city: "Anytown" } end it "valid? returns false for incomplete address" do expect( AddressValidator.valid?(@address) ).to eq(false) end it "missing_parts returns an array of missing required parts" do expect( AddressValidator.missing_parts(@address) ).to eq([:region, :postal_code, :country]) end end
In many cases, the object needs to change slightly from one test case to another. Local variables, local functions, or instance variables are tedious and make it hard to see the differences between test cases. For example, if we wanted to test for invalid characters in a city name, we would have the following:
describe AddressValidator do before do @address = { street: "123 Any Street", city: "Anytown" } end it "valid? returns false for incomplete address" do expect(AddressValidator.valid?(@address)).to eq(false) end it "missing_parts returns an array of missing required parts" do expect( AddressValidator.missing_parts(@address) ).to eq([:region, :postal_code, :country]) end context "invalid characters in value" do before do # notice the value for :city includes special characters @address = { street: "123 Any Street", city: "Any$town%" } end it "invalid_parts returns keys with invalid values" do expect( AddressValidator.invalid_parts(@address) ).to eq([:city]) end end end
- Mastering RabbitMQ
- 圖解Java數據結構與算法(微課視頻版)
- Hands-On Image Processing with Python
- 深入理解Django:框架內幕與實現原理
- Amazon S3 Cookbook
- Mastering Predictive Analytics with Python
- ArcGIS By Example
- Advanced Express Web Application Development
- Laravel Application Development Blueprints
- Emotional Intelligence for IT Professionals
- 深入分析GCC
- Visual C++程序設計與項目實踐
- Python編程快速上手2
- Java Web開發基礎與案例教程
- 現代C++語言核心特性解析