In an RSpec spec, how do describe, context and it relate to each other, and what does nesting groups actually build?

## The three building blocks An RSpec spec file is built from two kinds of objects: - An **example group**, created by `describe` or `context`. It is a container: it holds examples, nested groups, `let` definitions, hooks and helper methods. - An **example**, created by `it` (or its aliases `specify` and `example`). It is one runnable check with a description and a block. At the top of a file the group is usually opened with `RSpec.describe ShoppingList do ... end`. Inside it, plain `describe`, `context` and `it` are available as methods of the group. | Method | Creates | Typical argument | |---|---|---| | `describe` | example group | a class, or a method name such as `"#add"` | | `context` | example group (same method, other name) | a state: `"when the list is empty"` | | `it` / `specify` / `example` | one example | the behaviour: `"keeps one entry"` | There is **no behavioural difference** between `describe` and `context`: both are generated by the same internal helper and produce the same kind of group. The split is a reading convention, so that the printed output reads as a sentence. ## What nesting builds Each group is a Ruby **class**, and a nested group is a **subclass** of the group around it. That one fact explains most of RSpec's scoping rules: 1. Everything the outer group defines (`let`, `subject`, hooks, `def` helpers, included modules) is inherited by inner groups. 2. An inner group can redefine a `let` or a helper, and the inner definition wins for examples in that group, exactly like overriding a method in a subclass. 3. Definitions in an inner group are invisible to the outer group and to sibling groups. When RSpec runs an example, it creates a **new instance of the example's group class** for that example. Instance variables set in a `before` hook or in the example body therefore live on that one instance and disappear afterwards; the next example starts clean. ```ruby RSpec.describe ShoppingList do let(:list) { ShoppingList.new } describe "#add" do context "when the item is new" do it "stores it" do list.add("milk") expect(list.items).to eq(["milk"]) end end context "when the item is already present" do before { list.add("milk") } it "keeps one entry" do list.add("milk") expect(list.items).to eq(["milk"]) end end end end ``` ## How the description is assembled RSpec builds each example's **full description** by joining the descriptions of every enclosing group with the example's own. It inserts a space between parts, except when the parent argument is a class or module and the child string starts with `#`, `.` or `::`, in which case the two are glued together. The second example above is reported as: - `ShoppingList#add when the item is already present keeps one entry` This is why the conventions matter: a failure line that reads as a sentence tells you what broke without opening the file. ## Group body versus example body Code directly inside a `describe` block runs **once, when the file is loaded**, in the context of the group class. Code inside `it`, `before` and `let` runs **later, per example**, in the context of the group instance. Mixing the two up is a common junior error: - Calling a `let` helper from the group body (for example to loop over it and generate examples) raises `RSpec::Core::ExampleGroup::WrongScopeError`, because `let` values exist only inside examples. - Calling `describe` or `it` from inside an example raises the same error from the other direction. - Plain Ruby loops in the group body over literal data are fine; they simply call `it` several times while the file loads. ## Nesting as a design tool Good nesting mirrors the questions a reader asks about the object: - One outer group per class, one `describe` per public method, one `context` per interesting state or input. - Each `context` changes exactly one thing, usually by overriding a `let` or adding a `before`, so the difference from its siblings is visible in a few lines. - Deep nesting has a cost: past three or four levels a reader must scroll up through every enclosing hook to know what state an example starts from. ## Small things interviewers check - An `it` with a description but no block is reported as **pending**, with the message "Not yet implemented", so a list of planned behaviours can be committed before it is written. - `xit`, `xdescribe` and `xcontext` mark an example or group as skipped without deleting it. - Since every example has its own instance, examples can run in any order; order-dependence only appears when state escapes through something shared, such as a global, a class-level variable or a `before(:context)` hook.