RSpec Best Practices: Essential Tips for Readable Ruby Tests

**Do:**
- **Achieve full test coverage** by including happy paths, edge cases, invalid data, and error scenarios for every method. *Example:* For a user validation method, test valid emails, empty fields, and malformed inputs.
- **Enhance readability** with descriptive `describe`, `context`, and `it` block names, and always use `expect` syntax. *Example:* `expect(user.valid?).to be true` instead of `user.valid?.should be_true`.
- **Organize logically** using `describe` for classes/modules, `context` for scenarios, and `subject` to reuse the test object. *Example:* `subject { described_class.new(params) }` to avoid repeating instantiation.
- **Manage test data efficiently** with `let` or `let!` for lazy setup and FactoryBot for realistic objects over static fixtures. *Example:* `let(:user) { create(:user) }`.
- **Ensure test isolation** by making each test self-contained, using mocks for external services and stubs for methods. *Example:* `allow(UserService).to receive(:call).and_return(mock_data)`.
- **Eliminate duplication** via shared examples or custom helpers. *Example:* `shared_examples 'validates presence' do |field| it { is_expected.not_to allow_value(nil).for(field) } end`.
- **Support newcomers** with self-explanatory tests and comments on tricky logic. *Example:* Add `# Tests edge case where API returns 500` above complex mocks.

**Don't:**
- **Skip edge cases** – never test only typical inputs. *Counter-example:* Omitting nil checks leads to runtime surprises.
- **Use vague names** or `should` syntax, which reduces clarity. *Counter-example:* Avoid `it 'works'`; use `it 'returns user data for valid ID'`.
- **Nest tests deeply** or mismatch file paths. *Counter-example:* Don't put `spec/controllers/users_spec.rb` for `app/models/user.rb`; follow `spec/models/user_spec.rb`.
- **Rely on fixtures** or global setup, causing brittle tests. *Counter-example:* Hardcoded YAML data breaks with schema changes.
- **Share state** between tests or over-mock internals. *Counter-example:* Modifying a shared database connection affects unrelated tests.
- **Repeat code** without refactoring. *Counter-example:* Copy-pasting 10-line setups instead of using `let` blocks.
- **Assume deep knowledge** – avoid tests needing codebase tours. *Counter-example:* Unexplained complex stubs confuse junior devs.