Former Java engineer turned Ruby engineer who is trying to understand Ruby and Rails, MacOS and a lot of other things. Worked at Flywheel, FNBO, ACI Worldwide.
Nice writup on Rspec! I like to use describe/context for grouping tests and telling the story about what the class should and shouldn't do. Like you said, Rspec is all about making it human readable, so if you don't like how your test output reads, change it! Also helpful when you start getting into a bigger code base is to use shared examples with Rspec. So when you start pulling in concerns and modules that a class may use, you can easily set up spec that align with that concern but then test it in the class actually using the concern.
So for ex. if your Coffee was extend Drinkable in your rspec (coffee_spec.rb) you could call it_behaves_like "drinkable" which would call off to a RSpec.shared_examples "drinkable" example that you could define.
Exactly! I end up defaulting to RSpec for almost all my testing needs in real production code, because of that human readability, and all the great features inherent in it that help you write tests that make sense to you when you look back at them 2 months later, and forgot what you initially did. :)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Nice writup on Rspec! I like to use describe/context for grouping tests and telling the story about what the class should and shouldn't do. Like you said, Rspec is all about making it human readable, so if you don't like how your test output reads, change it! Also helpful when you start getting into a bigger code base is to use shared examples with Rspec. So when you start pulling in concerns and modules that a class may use, you can easily set up spec that align with that concern but then test it in the class actually using the concern.
So for ex. if your
Coffeewasextend Drinkablein your rspec (coffee_spec.rb) you could callit_behaves_like "drinkable"which would call off to aRSpec.shared_examples "drinkable"example that you could define.Exactly! I end up defaulting to RSpec for almost all my testing needs in real production code, because of that human readability, and all the great features inherent in it that help you write tests that make sense to you when you look back at them 2 months later, and forgot what you initially did. :)