require_relative '../price_entry_class.rb'require_relative '../exceptions.rb'require 'spec_helper'describe PriceEntry do    it throws expection on invalid date format do        expect { described_class.date_from_input_to_storage(20010101) }.to raise_error(InvalidInputData)        expect { described_class.date_from_input_to_storage(za) }.to raise_error(InvalidInputData)        expect { described_class.date_from_input_to_storage(nil) }.to raise_error(InvalidInputData)        expect { described_class.date_from_input_to_storage(-19_199) }.to raise_error(InvalidInputData)    endendIs it OK to have multiple expectations in a single Rspec test? rubocop-rspec claims that it would be preferable to separate this test into 4:spec/price_entry_class_spec.rb:14:2: C: Example has too many expectations [4/1].Claim that it is always better to have single assert in every unit test is quite surprising for me. Is there a good reason to split test like this into four separate ones?This test is testing only one thing at a time (is obviously malformed input resulting in exceptions).I can imagine rewriting it to[20010101, za, nil, -19_199].each do |malformed_input|    expect { described_class.date_from_input_to_storage(malformed_input) }.to raise_error(InvalidInputData)endbut I am not convinced that it is improving readability, maintainability or anything else.
Rspec test to confirm rejection of four invalid dates
ruby;datetime;unit testing;error handling;rspec
The reason is that if this test fails, you'll have to separately determine which of the 4 sub-expectations has failed.Depending on the output of your test reporter, this may or may not be a practical problem.This test is testing only one thing at a time (is obviously malformed input resulting in exceptions).Actually, you're testing:invalid digits raise an errornon-date characters raise an errornil raises an errornegative numbers raise an errorThat said, if you're essentially doing manual fuzzing and don't care about those distinctions -- though I'd say they seem useful in this particular case -- then I don't see an issue with this.  Testing rules and best practices are helpful, but don't get too bogged down in them.  If you know your own testing goals, and understand why it might be ok to depart from a best practice, by all means do so.