- 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
- 深入核心的敏捷開發:ThoughtWorks五大關鍵實踐
- 基于粒計算模型的圖像處理
- Offer來了:Java面試核心知識點精講(原理篇)
- Architecting the Industrial Internet
- Processing互動編程藝術
- Python數據可視化之Matplotlib與Pyecharts實戰
- 快速念咒:MySQL入門指南與進階實戰
- R Deep Learning Cookbook
- 網站構建技術
- Microsoft Azure Storage Essentials
- Java程序設計基礎(第6版)
- Instant Apache Camel Messaging System
- Python 3快速入門與實戰
- Real-time Analytics with Storm and Cassandra
- C#程序開發教程