- 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
- Learning Microsoft Windows Server 2012 Dynamic Access Control
- 多媒體CAI課件設計與制作導論(第二版)
- .NET之美:.NET關鍵技術深入解析
- 微信公眾平臺與小程序開發(fā):從零搭建整套系統
- MATLAB圖像處理超級學習手冊
- Apache Spark 2 for Beginners
- Flask Web開發(fā)入門、進階與實戰(zhàn)
- Getting Started with PowerShell
- NativeScript for Angular Mobile Development
- Python自然語言處理(微課版)
- Banana Pi Cookbook
- JavaScript+Vue+React全程實例
- Getting Started with Python Data Analysis
- Learning OpenStack Networking(Neutron)(Second Edition)
- Scratch3.0趣味編程動手玩:比賽訓練營