Currently AllowValueMatcher has a commented-out example usage, which should be uncommented when this is ready. Ideally the `if expected_message` nil-check in AllowValueMatcher will be handled by PositiveErrorDescription too. Use it in FormattedErrorDescription as well. We use PositiveErrorDescription#matches? and #matched_error to grab the description and return the correct thing in FormattedErrorDescription. I envision FormattedErrorDescription being used in AllowValueMatcher too, probably with a #matches? method too that delegates.
Currently Dis/allowValueMatcher uses the mixed-in pretty_error_messages method. Since DisallowValueMatcher isn't a perfect logical inverse of AllowValueMatcher, we need to have a third class that handles error messages for us. Future thoughts: Have a PositiveErrorDescription and a NegativeErrorDescription, which will compose FormattedErrorMessageList into a "Did not expect errors, got errors: " vs "Expected errors, got no errors". Idea: one of them can decorate the other and return the other's negative message as its positive message and vice versa.
An edge case occurs when mixing RSpec and Test::Unit tests and also loading both the 'rspec-rails' gem and 'shoulda-matchers' gem from the same Gemfile group, namely [:test, :development] . Work around this by always inserting the shoulda matchers into Test::Unit, regardless of whether RSpec is loaded.
A test for a validation with multiple scopes would always pass as long as there was a validation with the first scope. Subsequent scopes would pass verification because the first scope value had already been made unique.