A Deep Dive into RSpec Tests in Ruby on Rails(blog.appsignal.com)
blog.appsignal.com
A Deep Dive into RSpec Tests in Ruby on Rails
https://blog.appsignal.com/2024/02/07/a-deep-dive-into-rspec-tests-in-ruby-on-rails.html
9 comments
While I'm not currently using rspec, rswag/rswag is library for rspec I envy:
https://github.com/rswag/rswag
I'm currently using thoughtbot/json_matchers w/ partials of my OpenAPI spec, but its not nearly as user friendly:
https://github.com/thoughtbot/json_matchers
https://github.com/rswag/rswag
I'm currently using thoughtbot/json_matchers w/ partials of my OpenAPI spec, but its not nearly as user friendly:
https://github.com/thoughtbot/json_matchers
My only moments of joy derived from rspec is through rswag. But it pretty much (ab)uses rspec to give you design-by-contract for JSON api.
I would've enjoyed it more if it didn't try so hard to mimic a JSON schema language as an embedded DSL in ruby.
It's verbose and error prone, with the dubious benefit of looking familiar.
I would've enjoyed it more if it didn't try so hard to mimic a JSON schema language as an embedded DSL in ruby.
It's verbose and error prone, with the dubious benefit of looking familiar.
On a related note, I highly recommend Better Specs for spec-writing best practices:
https://www.betterspecs.org/
https://www.betterspecs.org/
That's the one that recommends using "let" everywhere, which is actively discouraged by RSpec documentation, which specifically states there should be at most 2 or 3 lets (sparingly)
https://www.rubydoc.info/github/rspec/rspec-core/RSpec%2FCor...
And it suggests using let (instead of the better let!) which when chained makes the execution of the code incredibly unpredictable for a human.
I suggest sticking only to instance variables and before blocks, so that overriding lets is not a practice that appear in your system and also won't push you toward abstracting your tests too much in an effort to improve performance
https://www.rubydoc.info/github/rspec/rspec-core/RSpec%2FCor...
And it suggests using let (instead of the better let!) which when chained makes the execution of the code incredibly unpredictable for a human.
I suggest sticking only to instance variables and before blocks, so that overriding lets is not a practice that appear in your system and also won't push you toward abstracting your tests too much in an effort to improve performance
Where does it say use let everywhere? I see only one section that explains let vs. let! and it makes no preference for the former: https://www.betterspecs.org/#let
> When you have to assign a variable instead of using a before block to create an instance variable, use let. Using let the variable lazy loads only when it is used the first time in the test and get cached until that specific test is finished. A really good and deep description of what let does can be found in this stackoverflow answer.
It omits entirely the warning and says "use this when assigning variable". Yeah you can make an argument either way, but given how dogmatic this website is, it's literally pushing toward using let. The consequence is that you get tests written with let everywhere.
I would outright say do NOT use let, like at all, your tests will be better without them:
It omits entirely the warning and says "use this when assigning variable". Yeah you can make an argument either way, but given how dogmatic this website is, it's literally pushing toward using let. The consequence is that you get tests written with let everywhere.
I would outright say do NOT use let, like at all, your tests will be better without them:
- A test abstraction could live in the actual code so that it's properly tested, it's plain ruby and can be used by other developers wanting to test code related to yours
- A test will have all the setup close to its execution phase, making it easier to read
- Instance variables override don't existOh man. It’s been a long time since I heard anything about rspec
If you do, why? How is it better in your view?