> Are there any particular advantages or disadvantages using the ruby let(:subject) { ... } syntax?

RSpec is giving you the `let` syntax — so it’s rspec specific.  

Advantages:
They can make for faster tests (they are lazy evaluated, meaning it won’t run unless that specific specification needs it). more: https://www.relishapp.com/rspec/rspec-core/v/2-6/docs/helper-methods/let-and-let
They can make for easier to use tests: the specification area (the `it “makes the things”) section is cleaner, and there is no setup code
You can override them in child contexts.


```
describe “Authorization” do

  context “new user” do
    let(:user) { User.new }
     
    it “does not allow access” do
    end

    it “has a code attached” do
    end

    context “subscription” do
      let(:user) { User.new(subscription: true) }

      it “allows access” do
        user.access?.should be_false
      end
    end
  end

end
```

Disadvantages
It can be difficult to remember what is created with the “user” with longer specs and multiple contexts



———————————————————

> So far from what I gathered, we write tests to express intent.  

As you get more advanced, you’ll discover that writing tests leads to a better design. But yes, tests should show intent, rather than implementation

> What would be some use cases where explicitly embedding the double and the class instance within the example test would be appropriate?

Something like this works — I think it’s where you definitely want your future self to KNOW that the ticket is a double

```ruby
it “should purchase the ticket” do
  ticket = double(“ticket”)
  ticket.should_receive(:purchase!).with(“the-event”)
  TicketMaster.purchase(“the-event”, ticket)
end
```

> For instance, if I am writing a custom class with 10+ instance methods, does it make sense to write a ruby let(:subject) { ... } once to create an instance and have it shared among the instance methods, or to explicitly create the instance with the example test?
  
I would create the instance itself, as long as you can create it without many pre-conditions.

Also note that a class with 10+ instance methods is likely a smell that it is doing too much, and that it should be refactored out to multiple coordinator classes (classes that work together, but each are small enough to be simple to generate and test).



On Tuesday, December 3, 2013 at 10:20 AM, Francis wrote:  
> In train_spec.rb:
> > > - let(:engineer) { Engineer.new } > - let(:conductor) { Conductor.new(engineer)} > +include Train  
> To specify the classes you need (and not every class) from a module after requiring makes sense. Given that Train is a namespace, I updated my tests to reflect your note.
> Are there any particular advantages or disadvantages using the ruby let(:subject) { ... } syntax?
> So far from what I gathered, we write tests to express intent. What would be some use cases where explicitly embedding the double and the class instance within the example test would be appropriate?
> For instance, if I am writing a custom class with 10+ instance methods, does it make sense to write a ruby let(:subject) { ... } once to create an instance and have it shared among the instance methods, or to explicitly create the instance with the example test?
>  
> —
> Reply to this email directly or view it on GitHub (https://github.com/RubyoffRails/train-message_expectations/pull/3/files#r8064830).
>  
>  
>