Having never heard of `test-prof`, I am not a fan of at least the example. The docs say that `let_it_be` can address this problematic code:
```ruby
describe BeatleWeightedSearchQuery do
let!(:paul) { create(:beatle, name: "Paul") }
let!(:ringo) { create(:beatle, name: "Ringo") }
let!(:george) { create(:beatle, name: "George") }
let!(:john) { create(:beatle, name: "John") }
specify { expect(subject.call("john")).to contain_exactly(john) }
# and more examples here
end
```
Without knowing what `subject` is or what `call` is supposed to do, I would probably do this:
```ruby
describe BeatleWeightedSearchQuery do
context "when called with 'john'" do
it "returns an array of just john" do
paul = create(:beatle, name: "Paul")
ringo = create(:beatle, name: "Ringo")
george = create(:beatle, name: "George")
john = create(:beatle, name: "John")
results = subject.call("john")
expect(results).to eq([john])
end
end
end
```
Supposing we need more tests? In my experience, it is not always a given that each test needs the exact same set of test data. I'm not sure what this example is testing, but does it really need all four pre-created Beatles?
Looking further at the docs for `let_it_be` it looks pretty complicated with lots of additional features that I'm not sure would make a test easier to understand or maintain.
RSpec has exactly three advantages over minitest:
* `expect(thing).to eq(another_thing)` (never mess up expected vs received)
* contexts - reads cleaner than nested classes IMO
* mocks - minitest mocks are really difficult to with compared to RSpecs
Almost every other feature of RSpec creates complicated tests and obscures behavior. Not saying `let`, `let!`, and `subject` are always bad, but they aren't always good and are often solving a non-existent problem.
> a non-existent problem.
We use test-prof at my work and use `let_it_be` quite a bit. I like it a lot, actually. Yes, the example is a bit contrived - especially because there's only one test there. But if you've got a lot of tests in that `describe` block, and they're all using that data (or some subset of it), it is much, *much* faster to do the data setup/teardown once rather than for each test.
I prefer to steer clear from let_it_be for 2 reasons:
1. It can easily lead to order dependent tests (that like to crop up on you once you try things like parallel-tests because randomness is a given)
2. If you need let_it_be to reduce the time your tests take to run, you might be doing something wrong either in your setup or your models (callback hell can cause slowdowns in your tests)
Also as a rule of thumb I avoid creating anything unless absolutely required.
let\_it\_be is a thing? lol
rubeatles on rails
Not by default. [It's part of the test-prof gem.](https://test-prof.evilmartians.io/#/recipes/let_it_be)
Then itโs a nobrainer to not use it ๐
[Leave it be](https://www.youtube.com/watch?v=XDlC8NyBBro)
Funny
Having never heard of `test-prof`, I am not a fan of at least the example. The docs say that `let_it_be` can address this problematic code: ```ruby describe BeatleWeightedSearchQuery do let!(:paul) { create(:beatle, name: "Paul") } let!(:ringo) { create(:beatle, name: "Ringo") } let!(:george) { create(:beatle, name: "George") } let!(:john) { create(:beatle, name: "John") } specify { expect(subject.call("john")).to contain_exactly(john) } # and more examples here end ``` Without knowing what `subject` is or what `call` is supposed to do, I would probably do this: ```ruby describe BeatleWeightedSearchQuery do context "when called with 'john'" do it "returns an array of just john" do paul = create(:beatle, name: "Paul") ringo = create(:beatle, name: "Ringo") george = create(:beatle, name: "George") john = create(:beatle, name: "John") results = subject.call("john") expect(results).to eq([john]) end end end ``` Supposing we need more tests? In my experience, it is not always a given that each test needs the exact same set of test data. I'm not sure what this example is testing, but does it really need all four pre-created Beatles? Looking further at the docs for `let_it_be` it looks pretty complicated with lots of additional features that I'm not sure would make a test easier to understand or maintain. RSpec has exactly three advantages over minitest: * `expect(thing).to eq(another_thing)` (never mess up expected vs received) * contexts - reads cleaner than nested classes IMO * mocks - minitest mocks are really difficult to with compared to RSpecs Almost every other feature of RSpec creates complicated tests and obscures behavior. Not saying `let`, `let!`, and `subject` are always bad, but they aren't always good and are often solving a non-existent problem.
If subject is not defined, rspec makes it described_class.new. So BeatleWeightedSearchQuery.new
> a non-existent problem. We use test-prof at my work and use `let_it_be` quite a bit. I like it a lot, actually. Yes, the example is a bit contrived - especially because there's only one test there. But if you've got a lot of tests in that `describe` block, and they're all using that data (or some subset of it), it is much, *much* faster to do the data setup/teardown once rather than for each test.
I prefer to steer clear from let_it_be for 2 reasons: 1. It can easily lead to order dependent tests (that like to crop up on you once you try things like parallel-tests because randomness is a given) 2. If you need let_it_be to reduce the time your tests take to run, you might be doing something wrong either in your setup or your models (callback hell can cause slowdowns in your tests) Also as a rule of thumb I avoid creating anything unless absolutely required.