Test EncodedSring#to_s for undefined conversion / invalid byte sequence #134

- Add tests for EncodedString#to_s, #split, #<< - For each Encoding failure - assert the expected failure is raised o a String, but not on an 'EncodedString' - assert invalid bytes or unconvertale characters are replaced Currently one test is failing (pending) - EncodedString#split when the string has an invalid byte sequence incorrectly raises an ArgumentError And I am unable to reproduce an Encoding::Compatibility error on the EncodedString object in Ruby > 1.9.2

For example, previously we would write our differ_spec expectations as actual = differ.diff(str1, str2) expect(actual).to eq(expected) Which had the suprising (but expected) result of failure diffing changing the string actual = differ.diff(str1, str2) actual != expected && RSpec::Expectations.fail_with(message, actual, expected) RSpec::Expectations.fail_with calls differ.diff(actual, expected) where differ is **RSpec::Support::Differ.new**( :object_preparer => lambda { |object| RSpec::Matchers::Composable.surface_descriptions_in(object) }, :color => RSpec::Matchers.configuration.color? ) So, all these differ_spec tests where we say expect(str1).to eq(str2) will run through the differ twice on failure. We should be testing them as expect(str1 == str2).to eq(true)

…ring

@expected

This was introduced in https://github.com/rspec/rspec-expectations/pull/220/files#diff-9533f5f156a38a3307ecfc610d2282d7R47 but is no longer raised either by the the current test code, the original test code @expected="Tu avec carté {count} itém has".encode('UTF-16LE') @Actual="Tu avec carte {count} item has".encode('UTF-16LE') or any other variations I've tried Since I'm moving all the encoding logic into EncodedString, and this doesn't appear to do anything any more, I am proposing to remove it. Next commits will also move over #pick_encoding Conflicts: spec/rspec/support/differ_spec.rb

/home/travis/build/rspec/rspec-support/spec/rspec/support/encoded_string_spec.rb:137: warning: possible reference to past scope - valid_unicode_string /home/travis/build/rspec/rspec-support/spec/rspec/support/encoded_string_spec.rb:142: warning: possible reference to past scope - valid_unicode_string https://travis-ci.org/rspec/rspec-support/jobs/45770204

https://travis-ci.org/rspec/rspec-support/jobs/45770207#L544 See travis-ci/travis-ci#3067 Per http://docs.travis-ci.com/user/ci-environment/ Use -Xcompat.version=2.0 per `jruby --properties` as `--2.0` wasn't being respected Note that script/functions.sh declares # idea taken from: http://blog.headius.com/2010/03/jruby-startup-time-tips.html export JRUBY_OPTS="${JRUBY_OPTS} -X-C" # disable JIT since these processes are so short lived

Some tests fail if the external/locale/filesystem encoding is ISO-8859-1 Rather than debugging environmental issues, we can control them per Ruby docs by running our CI specs via `ruby -E UTF-8 -S $spec_command`. See https://github.com/ruby/ruby/blob/ca24e581ba/encoding.c#L1674 Alternatively, we could control them via the environmental variables LANG, LC_ALL, LC_CTYPE in the .travis.yml or appveyor.yml with e.g. env: - LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8 (which is the default on Travis) ( http://docs.travis-ci.com/user/ci-environment/#Environment-variables ) but I'm not sure how windows-compatible that is and it appears more reliable to be explicit in the runner, so that running script/run_build uses the correct encoding, and one doesn't need to, for example, gem install wwtd && wwtd --local to get the CI behavior Also, see see https://github.com/rubyspec/rubyspec/blob/91ce9f6549/core/encoding/find_spec.rb#L57

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Test EncodedSring#to_s for undefined conversion / invalid byte sequence #134

Test EncodedSring#to_s for undefined conversion / invalid byte sequence #134

Commits on Jan 6, 2015