Maybe this is personal preference, but it's highly opaque to me what is being tested in those examples. Is it the method Thing#run_and_clear_props? Is it Thing#reset? Is it Thing#some_other_method? It seems like you're trying to say four things:

Thing#run_and_clear_props raises no error if properties are present
Thing#run_and_clear_props raises an error if the properties are blank
Thing#run_and_clear_props clears the props
Thing#reset restores the properties (to what is unclear - the state before #run_and_clear_props was called? The pristine state before we set properties?)

Only two of these statements are actually about errors (and IMO the first statement is not a valuable assertion). That leaves two statements, 3 and 4, that are being indirectly tested using repetition of statements 1 and 2. Surely it's far better to directly test them:

let(:thing) { described_class.new }

describe "#run_and_clear_props" do
  it "raises an error if no properties are set" do
    expect { thing.run_and_clear_props }.to raise_error
  end

  it "clears the properties" do
    thing.prop1 = val1
    thing.prop2 = val2
    thing.prop3 = val3

    thing.run_and_clear_props
    # make assertions about properties here
  end
end

describe "#reset" do
  it "resets the object to some condition" do
    # test whatever it is that #reset actually does
  end
end

It also seems that Thing#run_and_clear_props is doing too much (the name is a giveaway) - I would decompose it into #run and #clear methods that could be independently tested. This is my point, really - the necessity of eliding complex test actions using let or a test method is, to me, a code smell; it's an indication that we're testing something that needs to be broken down, or that there's some process or entity that we should be modelling in our application code, not our tests.

Test complexity is design feedback - we should eliminate it by improving our design, not by disguising it in our test suite.

Use let and let! #8

Description

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions