This app's payoff: RSpec, the framework it chose

One command, this app's output

bundle exec rspec spec/services/identity/account_update_service_spec.rb --format documentation

Identity::AccountUpdateService
  #call
    when updating basic info
      updates the user
    when changing the time zone
      saves a real zone
      rejects a name that is not a zone and keeps the old one
    when updating password
      updates the password when current password is correct
      fails when current password is incorrect
    when basic info and password are updated together
      does not persist the basic info change if the password update fails
      does not persist the basic info change if the new password confirmation does not match
      persists both changes together when everything is valid

Finished in 0.44975 seconds (files took 2.89 seconds to load)
8 examples, 0 failures

That's terminal output from this app's spec suite, unedited. Every indented line traces back to a describe, context or it in one file, spec/services/identity/account_update_service_spec.rb. This course's job is to show how that file produces that output.

Where this course picks up

The previous course, Minitest: model & assertions, started from a fact many courses skip: this app doesn't use Minitest for its own tests. It uses RSpec. That course covered a valid framework this app didn't choose. This one covers the framework it did choose, on its own terms, with the spec files in spec/.

Four building blocks, all from this app's spec files

RSpec.describe is the outer wrapper that names what's under test: a class (Identity::AccountUpdateService), or a class plus a plain string (lesson 2). context "when/with ..." do groups related examples under a shared premise; the file above has four of them (lesson 3). it "does something" do ... end is the example itself, and this app also uses a second, more compact style (lesson 4). let and let! build the data each example needs, one lazily and one eagerly, and this app's specs use each for its own reason (lesson 5). Lesson 6 covers the file-naming convention that connects every spec file back to the app code it exercises.

How the rest of this course was checked

The output quoted in the next six lessons, including the block above, came from running this app's spec files with bundle exec rspec ... --format documentation. None of it was written from memory of what RSpec output usually looks like. When a lesson says a spec file does something, that claim was checked against the file in this repository.