Testing Ruby with RSpec: The Complete Guide

The subject helper method lazily instantiates an instance of the class under test. This offers the developer several advantages including (1) one less let variable and (2) shorthand syntax for expectations that we'll discuss later. By default, subject assumes the class will have no initialization arguments. Within the same example, subject will memoize / cache the object when it's used multiple times. Between different examples, subject will instantiate a fresh object. In this lesson, we utilize subject to test a Ruby hash.

The subject method can be invoked outside of any example. The last evaluation of the block passed to the method will serve as its return value. This allows the developer to instantiate a custom object from the class under test to serve as the base "subject" for testing. A subject declared in an outer scope (i.e. an outer block) will be available to all inner, nested blocks.

The use of either an implicit or explicit subject grants access to a special one-liner syntax for writing an example. First, the it method is passed a block without a string argument. Next, the method is_expected is invoked as a replacement for the expect syntax. Finally, a regular RSpec matcher (such as eq) is attached to the end. In this lesson, we demonstrate both syntactical options side by side.

When a class is passed as an argument to the describe method, the class itself becomes available via the described_class method. It is advantageous to use described_class whenever the class is referenced because it makes the specs more adaptable to changes in business logic, such as the renaming of the class under test.

The RSpec.shared_examples method is used to define commonly used examples that can be injected into multiple example groups. The method is passed a string identifier and a block where all the examples are declared. Later, the include_examples is invoked within the body of an example group and passed the string identifier. Multiple shared examples can be used; it is common to store these in a separate helper file that is imported by other spec files.

A complement to shared examples, the shared_context method allows for multiple example groups to rely on common boilerplate code. The developer can reduce duplication by declaring before blocks, instance variables, helper methods, and let variables  in a shared context. The include_context method is then used to inject that context into multiple example groups.

This section is focused on the matchers available in RSpec. A matcher is a type of assertion, expectation or validation. RSpec includes a variety of matchers -- everything from equality to inclusion to identity to error raising. The not_to method is an alternative to the to method that checks for the inverse or negative of a given matcher. For example, not_to eq will check for inequality.

The eq matcher checks only for value equality. The stricter eql matcher checks for both value and data type. For example, eq would consider the integer value 3 and the floating point value 3.0 to be equal. eql would not consider the two equal because they are of different data types.

The equal matcher checks that two values are identical. To be identical, the values must both be the same object in the computer's memory. Identity is the strictest form of equality. In this lesson, we apply these matchers to arrays and introduce a real-life analogy of houses in a neighborhood.

RSpec includes support for numerical comparisons like greater than and less than or equal to. Use the be matcher followed by the proper Ruby operator. For example, expect(10).to be >= 5 will pass if 10 is found to be greater than or equal to 5.

A predicate method is one that returns a Boolean value -- either a true or a false. RSpec includes dynamic matchers for testing predicate methods. For any method, remove the question mark from the name and prefix it with be_. For example, the empty? method on an array can be tested with the predicate matcher be_empty.

The all matcher performs an aggregate check --- it validates that all elements in array fit some criteria. For example, expect([2, 4, 6]).to all(be_even) asserts that each value in an array is even. The matcher can also accept a mathematical comparison like be < 100 or be >= -2.

Ruby has two falsy values: false and nil. All other objects are considered truthy, which means that they evaluate to true in a conditional context. In this lesson, we introduce the be_truthy and be_falsy matchers for asserting truthiness / falsiness as well as the be_nil matcher for explicit comparisons to nil.

One of the most powerful matchers in RSpec, the change matcher compares the value of something before and after an operation. Pass the expect method a block with some code that may mutate an object's state. Afterwards, invoke the change matcher with another block that describes what value is being tracked. Several comparison methods are available: the from / to combo as well as by.

The contain_exactly matcher asserts that a sequence of elements is found within a collection, irrespective of order. The method is passed a comma-separated list of arguments to search for. If order matters, a more equality-focused matcher like eq would be used.

The have_attributes matcher confirms that an object has a set of attributes with corresponding values. The method accepts a hash where the key is the name of the attribute and the value is the corresponding attribute value. When testing a custom object, the attributes have to be publicly accessible via reader methods to be able to be checked.

The include matcher checks for the inclusion of an object within a larger object. It can be used to check for a substring within a string, a value within an array, a key within a hash, and even a key-value pair within a hash. This matcher is not concerned with order, only with presence.

The start_with and end_with matchers check for the presence of a smaller subset of elements at the beginning or end of a data structure. For a string, the matchers will check for a substring of characters. For an array, the matchers will check for the presence of elements in sequential order.

The raise_error matcher checks that a block of code triggers an error. It is recommend to pass the matcher a specific error to watch out for. Otherwise, it becomes difficult to ascertain whether the expected error was the one that caused the spec to pass.

The respond_to matcher verifies that an object can receive one or more given methods. The implementation and return values of the methods is not considered; this matcher checks only that the object has a method defined on its public interface. The additional with method confirms that the method is called with a specific number of arguments.

The satisfy matcher is used to define custom assertions. This offers the best opportunity for defining expectations that tie in to the business logic of your app. In this lesson, we use satisfy to check if a string is a palindrome.

The not_to method tests for the negative or inverse of any RSpec matcher. For example, not_to include affirms that an array does not include a value. In this lesson, we practice the syntax while reviewing many of the matchers introduced in this section.

Compound expectations can chain together two or more expectations. The and method ensures both of the matchers pass while the or method ensures either of the matchers pass. In this lesson, we explore the syntax in the context of a randomness problem.

A double is a stand-in for a real object in a test. Doubles allow us to isolate specs to test app components (such as classes) independently. In this lesson, we create a sample stuntman double and walk through the syntax to permit and receive methods on it.

In this lesson, we do some light prep work to set up the upcoming tests. All examples are tied to the real-life situation of a movie set with real actors and stunt doubles.

In this lesson, we replace our real object with a test double, connecting the ideas introduced in the last two lessons. The allow method defines a mock method on a double and the expect method affirms that it is called.

In this lesson, we introduce new methods like at_most, at_least, once, and exactly to test how many times a method was received on a double. The method counts are not independent between different assertions so these methods cannot be stacked.

The allow method is incredibly versatile -- it can be customized to respond to different arguments as well as return different return values. In this lesson, we use the method to create a double that mocks the functionality of a Ruby array.

A method stub’s return value can be customized depending on the number or arguments, the type of arguments, or specific argument values. The ​with​ method specifies the number of expected arguments. In this lesson, we continue exploring how we can modify the allow method.

Verifying doubles are stricter alternatives to normal doubles. RSpec checks that the methods being stubbed are present on the underlying object. The ​instance_double​ method takes a class name or object as its argument. It verifies any method being stubbed would be present on an instance of that class.

Class doubles mock a class and its class methods rather than its instance methods. One advantage of ​the class_double​ method is that the class itself have to be defined -- this allows for test-driven development.

Spies are an alternate type of test double. They spy / observe the behavior of an object and all of the methods it receives. Spies follow a different pattern than a double -- they assert a message has been received after an action.

In this lesson, we practice using spies with a Garage / Car class combo.

Congratulations on making it to the end of the course! I hope the course has been as fun to watch as it was for me to produce. Best of luck in all of your coding endeavors!

Explore the bonus content for the course!